一个 Agent 说“完成了”，团队为什么没放行？

CodeFlowMu 多 Agent 防幻觉实战

这不是模型层面的“幻觉检测”。而是协议与组织结构层面的治理：FCoP 作为 Agent POSIX 外化事实CodeFlowMu 作为应用与 Runtime 运行角色，PM 依据证据决定是否放行。老实说，

使用者痛点

• 团队常收到看似完整的“完成”报告。却缺乏可靠的验证手段，
• 缺少统一的证据收集机制，导致错误在验收、发布环节被放大。
• 角色职责混淆。使得开发者交付成功，风险难以追溯。不过，
• 工具异常时程序仍默认成功。增加故障隐蔽性，不过，

现场概述

下午 点 分一个 DEV 子执行返回了 completed。它给出的很完整：实现思路、测试命令、提交说明、剩余风险，看起来像一份可以直接交给 PM 的工作回执。但同一份原始事件里还埋着三句话：

一边是“完成了”，另一边是“无法确认是否执行成功”。

幻觉发生在一个 Agent 里事故发生在团队把它当真时

我们经常把“防幻觉”理解成让模型更聪明：换更大的模型、补更长的提示词、再加一个自我反思步骤。这些方法有价值，但仍然把希望寄托在同一个主体身上：让说错话的人自己证明自己没有说错。

多角色、多事实来源的治理框架

• DEV：负责实现。可犯错，也可能因工具异常产生错误判断；
• PM：负责判断交付事实是否满足任务合同，不能把 DEV 的自述当成证据；
• QA：负责以分离角色重新验证，不能只复述 DEV 报告；
• Runtime：负责唤醒、调度、恢复、界面和实时操作流，但不替 PM 作业务裁决。

现场的观点是，上部是 PM 的事实判断。底部是 Agent 的实时操作流

下面这张图不是后期制作的流程示意，而是当时 CodeFlowMu 业务程序中的真实现场。上部展示 PM 与任务事实；底部保留了 Agent 的实时操作流与可见思考摘要。说起来，最关键的一句话不是 DEV 的自述，而是 PM 已经作出的判断：

PM 在核对磁盘、Git、REPORT 和任务状态后给出的业务裁决。把 completed 从一句容易被接受的语言声明降回“证据不足，不能放行”。左侧 PM 看到了以下事实：

• TASK REPORT 不存在；
• Git HEAD 仍属于前一个 WP；
• 任务要求的测试文件尚未完整落盘；
• SHELL 多次返回 No exit status;
• S子执行承认测试未确认、SHA 不可得。

P M 决策：

• No QA dispatch;
• No new duplicate task;
• Continue original task.

五个角色动作，把一句“完成了”变成可验证的交付

再看第一幕。DEV 的工具通道失去确定性

D EV 已经完成了部分实现，但 Edit、Shell、Read 等工具连续返回异常状态。最关键的是工具无法提供可靠的退出状态——没有退出状态，就不能证明命令执行了；没有输出，就不能证明测试通过了；怎么说呢，没有 commit，就不能证明代码已经形成可追踪交付。

说到第二幕，子执行生成了一个很像完成报告的答案

///...