建立反馈闭环与独立复核

Agent 的一句“已经完成”不是验收证据。可靠工作流需要把执行结果送进反馈环：修改、运行检查、读取真实输出、定位失败、再次修改，直到满足事先定义的完成条件。

反馈的四个层级

只运行最便宜的一层不够；也不必每改一行就运行最昂贵的全量测试。计划中应说明何时升级验证强度。

让工具结果成为下一步输入

DeepSeek Harness 把工具调用与结果写入 Session，模型可以在后续步骤使用这些事实。提交任务时明确要求：

每次检查都读取真实退出码和失败摘要。
不得根据“命令已发出”推断测试通过。
如果检查失败，先归类为本次回归、既有失败或环境失败，再决定下一步。

避免只贴数千行日志。保留命令、退出码、关键错误、首个根因和完整日志位置即可。

设计分层验证矩阵

假设修改一个 API：

1. 改单个函数后运行相关单元测试。
2. 改路由或 Schema 后运行类型检查和 API 集成测试。
3. 完成后运行项目规定的 lint、build 与目标测试套件。
4. 涉及平台差异时，在另一环境或 CI 上复核。

每个验证项都写成“命令 + 预期信号 + 失败处理”，而不是笼统的“测试一下”。

独立复核为什么有用

让同一个上下文先实现再自评，容易重复原始假设。独立 Reviewer 不需要重新完成任务，它需要从任务契约、diff 和验证证据出发寻找反例。

Reviewer 提示模板：

你是只读审阅者。根据任务契约审查 diff：
1. 找出正确性、安全性、兼容性和测试覆盖问题。
2. 每项结论必须引用文件/位置和触发场景。
3. 区分阻塞问题、建议和无法确认事项。
4. 不修改代码，不重复实现者的总结。

可以用新会话、Fork 后的审阅分支或子智能体承担复核；关键是减少与实现者共享的未验证推断。

失败分类

• 本次回归：修改前通过、修改后失败，优先修复。
• 既有失败：在干净基线也失败，记录证据并判断是否在范围内。
• 环境失败：缺服务、权限、网络或平台依赖，不能冒充代码通过。
• 不稳定失败：重复结果不一致，应保留频率和运行条件。

完成报告模板

变更：修改了哪些行为和文件。
验证：命令、退出码、通过数量。
复核：独立审阅发现及处理结果。
未验证：受环境限制未运行的检查。
风险与回滚：剩余风险、恢复步骤。

练习时故意制造一个测试失败，观察 Agent 是否读取真实输出、正确分类并停止“宣布完成”。下一篇处理上下文压缩、会话与 Fork。