Harness Engineering 工程实践

Harness Engineering 工程实践

当我们让 AI Agent 实现一个功能，它思考了一下，开始写代码。200 行写完，运行 lint 直接失败。我们发现类型定义文件 import 了配置包，但是违反了我们期望的架构分层约束，因为 Agent 不知道这个规则，当然我们也没告诉它。

于是它开始修复：移动代码、调整依赖、重新组织。再跑 lint——又一个新问题。循环三次后，上下文窗口被错误日志和 diff 塞满，Agent 开始"忘记"最初的任务目标。

这不是 Agent 不够聪明。这是 Agent 看不见。

你可能也遇到过类似的事情：同一个项目，昨天的 AI 还记得你们的架构约定，今天开个新会话又全忘了。每次协作都要重新解释一遍背景、分层规则、命名规范。AI 生成的代码能跑，但完全不符合团队规范，code review 时才发现一堆问题。让它修 bug，结果引入了新 bug——没有自动验证，全靠人肉检查。

如果换成一个新入职的工程师，他可能也不熟悉代码库，但至少会问一句：“这个文件应该放在哪个目录？”"这样 import 可以吗？"他在行动前寻求验证。AI Agent 不会。它直接干。

问题出在哪？Prompt 写得再好，也没法穷尽代码库的所有隐式规则。上下文窗口再大，也装不下整个仓库的架构决策。“教得更好"这条路有天花板——写更详细的 system prompt，提供更多示例，规则会随代码演进变化，你永远追不上。规范文档放在 钉钉 或 Notion 上，AI 读不到；依赖 AI 的"常识”，不同模型表现差异大，不可靠。

Harness 工程的思路不一样：与其教 Agent