面试防线：如何防止 Agent 伪造开发证据 (Dev Evidence)？
面试官提问：
“你提到你们有一层很关键的设计叫 Review Gate，要求 Crafter Agent 提交开发证据（Dev Evidence）。大模型最擅长的就是幻觉和骗人，你怎么保证它提交的测试结果或修改记录是真的，而不是它伪造出来的？”
核心回答思路 (STAR法则)
-
业务痛点 (Situation)
在引入“证据驱动的质量门禁”初期，我们确实遇到了这个问题：如果我们只要求大模型在聊天框里回复“我跑了测试，一切正常”，它有很大的概率会“撒谎”，因为 LLM 本质上只是在补全文本，它实际上并没有真正的运行环境。 -
技术考量 (Task)
为了打破这种“单方面陈述”的信任危机，我们必须在系统底层实现真正的客观验证机制。系统不能信任大模型主观生成的“文本”，必须信任底层沙箱产生的“客观输出”。 -
架构决策 (Action)
我在系统里设计了“零信任”的证据收集协议：
- 底层沙箱拦截 (Sandbox Execution)：Crafter Agent 并不是在真空中思考，它的每一个 Bash 命令、每一次测试脚本运行，都必须通过我们的 ACP (Agent Client Protocol) 接口下发到底层的安全沙箱（如 Docker 容器或特定的本地隔离 Worktree）中执行。
- Harness Monitor 客观采证：证据根本不需要大模型自己去“写”。我们在底层有一个 Harness Monitor（操作链路监控器）在旁路监听。当 Agent 调用了
npm run test或修改了某个文件时，Monitor 会把真实的 Exit Code（退出码）、Stdout/Stderr 以及真实产生的文件 Git Diff 自动抓取下来。 - 证据的自动拼装与上链：当卡片准备流转到 Review 列时，系统会自动将 Monitor 采集到的这些不可篡改的“客观日志”拼装成一份结构化的 Dev Evidence 附加在卡片上，而不是去问 Agent“你做了什么”。
- 业务价值 (Result)
通过引入底层的客观沙箱和旁路监控，我们彻底剥夺了大模型“伪造证据”的能力。下游的 Review Guard Agent 在审查时，面对的不再是上游大模型的巧言令色，而是实打实的底层系统运行日志。这构成了我们系统中不可逾越的质量红线，实现了真正的 0 信任流水线交接。