EviFleet｜证巡

证巡 EviFleet 面向 AI 应用的可验证协作运维系统 调查有据，处置有界，恢复可验。 一、我们要解决什么问题 AI 应用的故障，不一定表现为服务宕机，也可能是“系统仍在运行，用户的任务却没有正确完成”。 例如，用户要求查询订单和退款资格，并明确表示不要转人工，客服 Agent 却误读了请求，直接结束查询并转交人工。接口返回成功、页面显示回复，并不意味着业务目标已经达成。 证巡关注的正是这类异常：应用究竟做了什么、哪里偏离了用户要求、判断依据是否充分，以及处理之后是否真正恢复。 当前原型以客服 Agent 为场景，将业务执行、异常调查和受控处置放在同一条可追溯流程中。 二、证巡是什么 证巡不是另一个替用户回答问题的客服机器人，而是帮助开发者和运维人员检查、调查和处理 AI 应用异常的协作工作台。 它连接应用的运行轨迹、对应版本的相关源码与业务规则，将这些信息组织为调查证据，再由不同 Agent 分工分析、提出反例和复核解释。操作者可以查看成员之间的交接记录、结论依据与分歧，审核处理建议，而不必只接受一个无法追问依据的最终答案。 对于已有适用预案的问题，操作者可以进一步授权具体变更。执行完成后，系统通过独立的业务检查判断结果，而不是让提出建议的模型给自己打分。 三、核心工作流程 业务执行 → 观察异常 → 协作调查 → 审核建议 → 独立授权 → 执行预案 → 验证恢复 → 审核经验 观察应用实际执行。 用户向接入的应用提交业务任务，应用实际调用模型和业务工具。证巡展示执行步骤，并读取应用侧 Langfuse 观测，将调用输入、输出、工具结果与源码版本关联起来。明确的观察规则负责标记错误、意外写入、异常转交等疑点；正常的澄清或能力边界不会一律被当成故障，操作者也可以主动发起核查。 让不同 Agent 相互核查。 调查成员根据分配到的证据提出原因假设；复核成员先独立准备反例问题，再检查调查解释是否成立；协调成员汇总结果，形成带有证据引用的建议。证据不足时，系统允许保留“需要补充资料”或“暂不下结论”，而不是强行生成一个确定的根因。EvoMap 原生会话用于任务、证据与结果交接，本地运行时负责调度、模型调用和任务状态管理。 把建议认可与执行授权分开。 认可一份调查建议，不代表允许 Agent 修改业务系统。当前原型支持由操作者选择固定的客服路由保护预案，单独审核并授权。执行前，系统检查预案摘要、目标源码、当前配置和运行进程归属，再实施配置调整与受控重启。模型不能通过一段自然语言建议直接获得任意执行权限。 用业务结果判断是否恢复。 配置生效只是中间步骤。系统还会重放原任务、执行正常业务探针、核对工具回执与示例数据库中的事实，并检查业务数据是否发生不应有的变化。只有相关检查通过，且审批、执行、验证与恢复记录关联一致，才将同一事故标记为已恢复。人工回退属于另一项操作，不能被当成业务恢复的证明。 留下可追溯的经验。 通过验证的处置可以形成经验候选，经人工审核后供后续调查参考。复用范围受到应用、环境、源码版本和策略约束；历史经验不替代当前证据，也不会自动授予修改权限。 四、多智能体的价值，不只是增加几个角色 证巡采用多智能体，不是为了让多个模型重复回答同一个问题，而是建立不同职责之间的制衡：调查者解释异常，复核者寻找解释的漏洞，协调者整理分歧，操作者决定是否采取行动，独立业务检查负责验证结果。 这种设计希望降低“一个 Agent 判断错误，却一路执行到底”的风险。成员交接也保留证据和任务记录；当前原型提供成员暂停与接力演练，拒绝暂停成员的迟到结果，并支持其他成员在显式继续调查后接手。 同时，证巡不预设多智能体一定优于单 Agent。工作台保留基于同一组业务证据的单 Agent 与协作团队对照，展示双方的调查结论、耗时和模型用量，让团队判断更深入的核查是否值得额外投入。 五、当前原型与发展方向 当前原型以本地运行的客服 Agent 和示例业务数据为验证场景，接入应用侧 Langfuse 观测与 EvoMap 会话协作，提供调查建议审核、固定路由保护策略的独立授权、配置执行、业务验证及经验审核流程。 当前处置能力是预设配置方案，不是模型自动生成并部署任意代码补丁。 多用户权限、任意应用接入、通用动态规划、远端经验发布与长期生产稳定性，仍属于后续建设和验证范围。 证巡面向需要维护 AI Agent、智能客服及其他 AI 工作流的开发团队。后续将围绕更多应用适配器、可授权处置方案和业务验收规则扩展，让不同场景都能回答三个问题：为什么这样判断、实际改变了什么、结果如何证明。 我们的目标不是让 AI 不受约束地接管运维，而是让 Agent 协作查明问题，让人掌握处置权限，让证据决定是否恢复。