Coding Agent 落地的 Harness 由哪些具体组件构成？
| 组件 | 回答的问题 | 工程实现 |
|---|
| 验收基线 | 什么算做完了 | 测试套件、CI 管道、代码审查标准 |
| 执行边界 | 能碰什么不能碰什么 | 模块边界、依赖规则、权限控制 |
| 反馈信号 | 对错如何自动判断 | Linter 输出、测试结果、类型检查错误 |
| 回退手段 | 出问题怎么恢复 | Git 版本控制、沙盒隔离、快照回滚 |
为什么 Coding Agent 特别适合 Harness 工程？
| 结果可自动验证 | 结果需人工验证 |
|---|
| 目标明确 | 最佳区域：修复有测试用例的 bug | 吞吐量受限：代码重构需人工审查 |
| 目标模糊 | 高效地跑偏：用 linter 优化“代码质量” | 难以启动：“让 UI 更好看” |
- 判据: 用任务清晰度与验证自动化程度两个维度划分四象限;
- 目标: Harness 就是把尽可能多的任务推向“目标明确 + 验证自动化”象限;
- 天然优势: 测试套件提供验收标准、Linter 与类型检查器提供即时验证、Git 提供版本控制与回退;
- 结论: Coding Agent 成熟度最高不是因为代码生成模型特别强，而是软件工程几十年积累的基础设施天然构成了一套强 Harness;
三项业界实践给出了什么结论？
- 大规模代码迁移: 关键不在模型强，而在 Harness 做对三件事——知识必须存在于代码库本身（Agent 看不到的等于不存在）、约束编码进 Linter 与 CI 而非写在文档里、验证与纠正全链路自动化;
- LangChain: 仅优化 Harness（系统提示词、工具中间件、自验证循环）就显著提升基准表现；尤其以“用 Agent 分析失败轨迹来改进 Harness”把 Harness 工程从人工经验驱动转向数据驱动;
- Anthropic: 把长任务拆成初始化 Agent（分解出任务清单）与执行 Agent（逐步推进并留下中间成果），解决长时运行“一次想做太多”或“过早声称完成”的问题;
可迁移到所有 Agent 的四条设计原则是什么？
- 约束优先于指导: 能用代码强制的规则就不要用文档建议——Linter、类型约束、CI 检查是“做不了”，提示词里的“请遵循”只是“建议别做”;
- 验证要自动化: 人工审查是不可扩展的瓶颈，测试套件、质量检查、行为监控的投入回报率远高于增加人力;
- 反馈越快越好、越结构化越好: 错误信息越详细、越接近错误发生时刻，纠正效率越高;
- 回退要可靠: Agent 只有在安全网内操作才敢大胆试错，Git 分支、沙盒、快照确保错误可逆;
为什么约束要管动作而不只是结果？
- 区别: 验收基线管结果对不对，执行边界管过程——结果正确但方法错误也不行;
- 破坏性捷径一: 修复数据库故障时直接删库重建，“修复”生效但数据没了;
- 破坏性捷径二: 修复编译错误时把代码全删重写，编译通过但实现没了;
- 加固: 即使把限制写进最终评估指标，Agent 也常能找到绕过的办法，这是 reward hacking 在 Agent 任务中的日常形态;
- 生产措施: 对
rm -rf、删除生产数据、覆盖未读文件这类危险动作设置专门检查与审批;
- 训练侧对应: 验证路径惩罚（RLVP）在结果奖励之外对过程中可验证的违规动作施加惩罚，把“不用破坏性手段”内化为工程常识;
- 关系: 对已有模型，Harness 护栏是外部约束；对可训练模型，过程惩罚是内部内化——目标一致;
并行工具调用时故障如何传播？
- 问题: Harness 视角下成熟 Coding Agent 支持并行工具调用，独特问题是故障如何传播;
- 原则: 故障只在同一批并行调用内传播，不上升到父级操作;
- 例证: 同时读取三个文件，其中一个找不到时只报告这一个失败，不取消另外两个，更不中止整个任务;
- 收益: 避免“一个命令失败导致整个任务中止”的脆弱模式;
- 机制细节: 见 CodingAgent 的实现技巧;