当你用Codex、Cursor或其他AI编码代理处理真实项目时，经常会出现这种场景：它能快速生成一段看起来很合理的代码diff，甚至通过了表面检查，但一到集成、review或者上线就露出各种问题。

你可能会先怀疑模型不够强、上下文不够多，或者prompt写得不够聪明。但在反复实践后会发现一个更根本的原因：问题往往出在Agent被放置的环境上，而不是模型本身。

Google Kaggle白皮书《The New SDLC With Vibe Coding》里最务实的一点，正是把注意力从“模型竞赛”拉回到“系统构建”——他们把围绕模型的一切称为Harness（工作面/安全带）。这个概念直接击中了当前Agent使用的最大痛点：我们把太多精力花在单次prompt上，却很少系统性地设计Agent赖以生存的整个工作环境。

Harness到底包含什么

Harness不是一个模糊的概念，而是由几类具体组件构成的完整系统：

• 指令与上下文：Repo级README、任务描述、相关issue和文件
• 工具与沙箱：Agent能安全访问和修改的范围
• 护栏与边界：什么能改、什么绝对不能碰
• 评估与验证：明确的检查命令、测试、冒烟测试或评分标准
• 可观测性与记忆：变更记录、验证结果、风险留存

当Harness清晰时，Agent往往能产出高质量、可维护的变更；当Harness缺失或模糊时，再强的模型也容易产出“看起来对、实际脆”的代码。

这就像给一个技术能力很强的承包商盖房子。如果你只说“帮我建个房子”，结果大概率是各种返工。但如果你提前给出图纸、材料清单、变更控制流程、验收标准和移交文档，同一个承包商就能稳定交付。

每个严肃任务都应该携带的5个结构化字段

我把白皮书里的思路落地成一个极简但极有效的任务模板。任何值得认真对待的Agent任务，都应该先填充这几个字段：

Mode（模式）：prototype / standard / production
决定Agent的激进程度和风险容忍度。

Context（上下文）：明确指出repo、issue、源文档或关键文件路径。
避免Agent用过时或无关的代码做决策。

Boundary（边界）：什么可以改，什么绝对不能碰。
例如允许修改src/和tests/，但禁止动package.json和基础设施配置。

Verification（验证）：精确的验证命令或检查方式。
可以是 npm test && npm run lint，也可以是Playwright脚本、人工review checklist，甚至是一个评分rubric。

Handoff（移交）：变更了什么、通过了哪些检查、还剩下什么风险。
这是Agent完成工作后留给人类（或下一个Agent）的结构化记录。

这五个字段不是行政负担，而是让Agent从“聊天窗口里的魔法师”变成“在明确系统里执行的工程师”。

Agent应该扮演的多个角色，而非单一“写代码”

一个设计良好的Harness会引导Agent依次或按需切换角色：

• Critic（批评者）：在写代码前先评估任务清晰度、风险和现有代码路径
• Builder（建造者）：在目标明确后生成变更
• Verifier（验证者）：在声称完成前执行检查
• Recorder（记录者）：把变更、验证结果和风险结构化保存下来
• Coordinator（协调者）：当多个独立任务可以安全并行时，负责调度

这种角色切换不是靠prompt里的“请先思考再行动”这种口头禅实现的，而是通过Harness里的验证和边界机制自然驱动的。

Prompt-centric vs Harness-centric 的真实差异

维度	仅靠Prompt优化	Harness结构化工作流	实际影响
输出一致性	波动大，依赖运气	显著提升，通过外部验证锚定	更少返工
风险控制	事后发现	事前通过Boundary和Verification控制	生产环境更安全
并行能力	困难	容易（每个任务有清晰边界和停止条件）	工程师注意力大幅释放
可追溯性	几乎没有	完整的变更+验证+风险记录	团队协作和审计友好
长期维护成本	高（每次都要重新理解上下文）	低（Harness可复用、可演进）	系统级生产力提升
人类判断位置	事后review每一次输出	前置到定义Mode、Boundary、Verification	判断更少但更关键

这个对比不是理论，而是真实切换工作流后的感受总结。越是复杂的、重构类的、生产级的任务，Harness的杠杆效应就越明显。

把Harness当成软件系统的一部分来对待

起初很多人（包括我）都把Agent当成一个更聪明的聊天窗口，觉得只要prompt写得好就行。后来在处理真实代码库时才发现：prompt只是界面，Harness才是底层架构。

一个好的Harness会产出五样东西，而不仅仅是一个diff：

• 变更内容
• 变更理由
• 明确边界
• 验证结果
• 结构化移交

这正是从“让Agent写代码”进化到“让Agent在系统中可靠工作”的关键转变。

当前阶段，人类判断没有消失，只是被前置了。你要做的不是实时盯着每一次生成，而是提前把“盒子”建好——决定模式、划定边界、定义完成标准。Agent可以在盒子里快速移动，但盒子本身需要人类来设计和维护。

这套思路和之前分享的“可验证循环 + 异步通知”高度互补：Harness提供了结构和锚点，循环提供了执行机制，两者结合才能让Agent真正成为可扩展的生产力组件，而不是一次性玩具。

你目前在用AI编码代理时，哪个环节最容易因为缺少清晰Harness而翻车？是上下文经常过时、边界模糊导致越权修改，还是验证标准不明确导致“看起来完成了其实没完成”？把你的具体卡点说出来，我们可以一起拆解如何为它设计一个最小可用的Harness。

我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。