记住 Agent 工程从 Prompt → Context → Harness → Loop → Self-Harness → Environment 的演进已到了 Environment 阶段去年这个时候我还在纠结怎么写 Prompt 能让 Claude 少胡说八道。今年这个时候我已经不聊 Prompt 了。不是因为它不重要是因为真正卡住 Agent 的早就不是「怎么说清楚」而是「让它住在哪里」。这个转变我自己是慢慢意识到的。第一个阶段Prompt 工程刚开始用 Claude Code最大的兴奋点是「它能听懂我说什么」。我描述一个需求它生成代码基本能用。那时候我觉得AI 编程的核心竞争力就是「把话说清楚」。于是我开始研究 Prompt 技巧角色设定、Few-shot 示例、Chain-of-Thought、结构化输出……每学会一招代码质量就提升一点。但很快遇到天花板。同一个 Prompt今天好用明天换个项目就不行了。因为项目背景变了但 Prompt 没变。它不知道你的技术栈、你的分层规范、你的命名约定。Prompt 解决的是「这一步怎么说清楚」但工程不是一步是一万步。第二个阶段Context 工程于是我开始往上下文里塞东西。CLAUDE.md、项目文档、历史对话、代码摘要……能塞的都塞进去。效果确实好了。Claude 知道我们项目用 Java 21、Spring Boot 3.4、构造器注入、DTO 不能暴露 Entity。它生成的代码终于能过 Code Review 了。但新问题出现了上下文太长Agent 会「失忆」。你塞了 20 个文件它只「记得」最后 5 个。你纠正过它一次下次对话又忘了。更麻烦的是上下文是静态的。你昨天定的接口方案、上周踩的坑、上个月做的架构决策不会自动出现在今天的对话里。每次都要手动搬搬着搬着就漏了。Context 解决的是「这一步该给它看什么」但看的东西不会自己更新。第三个阶段Harness 工程这时候我开始接触 Harness。简单说就是给 Agent 套一个「运行时框架」——工具怎么调用、权限怎么控制、状态怎么保存、失败怎么重试、什么时候停下来。装了 Harness 之后Agent 终于不是「裸奔」了。它有工具箱了有安全边界了有日志和 trace 了。我可以放心让它跑一些自动化任务比如批量重构、生成测试、检查代码风格。但跑了一段时间又发现一个怪事Agent 越跑越蠢。不是模型变弱了是它一直在同一个环境里打转学不到新东西。它修了一个 Bug下次遇到类似的还是从头摸索。它优化了一段代码但不知道这段优化在真实环境里有没有副作用。Harness 解决的是「让它怎么跑起来」但跑起来之后能不能学到东西是另一回事。第四个阶段Loop 工程于是我开始设计 Loop。让 Agent 能持续跑——修完一个 Bug 自动找下一个写完一个功能自动跑测试测试不过自动重试。Loop 让 Agent 从「一次性工具」变成了「长期运行的 worker」。它可以处理 PR、聚类反馈、批量改代码甚至自己开分支、提 PR。但 Loop 也有坑。没有停止条件的 Loop就是无限循环。我见过 Agent 在一个文件上反复修改改完 A 破坏 B修完 B 又破坏 A折腾了 20 轮还在原地打转。更隐蔽的问题是Loop 跑得快不代表跑对了。如果反馈不可靠Agent 可能围绕噪声做优化越跑越偏。Loop 解决的是「怎么持续跑」但跑的方向对不对取决于它看到的世界真不真。第五个阶段Self-Harness 工程这时候我开始想能不能让 Agent 自己改进自己失败之后它能不能总结经验踩过坑之后能不能记住教训跑了几轮之后能不能优化自己的 Harness这就是 Self-Harness 的思路。把轨迹、证据、回归测试、Harness 版本都纳入循环让 Agent 在失败中「长记性」。但这里有一个前提失败必须是真实的经验必须是可验证的。如果 Agent 以为自己「修好了」但实际上只是测试没覆盖到失败路径那它学到的经验就是错的。错的经验写进长期记忆下次还会再犯。Self-Harness 解决的是「失败后怎么改一点自己」但改得对不对取决于它面对的世界是不是在说真话。第六个阶段Environment 工程走到这里我终于意识到真正卡住 Agent 的是它「住」的地方。不是模型不够强不是 Harness 不够细不是 Loop 不够快。是 Agent 行动之后它所在的环境能不能给出可靠反馈。举个例子你让 Agent 修 CI 失败。它只能读日志不能跑测试——那它很可能写一段「看起来合理」的解释实际上没修。它能跑测试但测试本身不稳定——那它可能围绕噪声做优化今天修好了明天又坏。它有隔离 worktree、可重复测试、清晰的失败日志、提交前检查——那它才有机会把「看起来修好了」变成「证据显示修好了」。同一个 Agent同一套 Harness放进三种环境里会长成三种完全不同的行为。这就是 Environment 工程要解决的问题Agent 到底在哪个世界里做事这个世界会不会骗它一个环境最少要回答五个问题状态在哪里——Agent 能看什么看到的是不是真实的动作有哪些——它能做什么哪些动作有副作用观察怎么回来——命令输出、测试报告、截图分别怎么进入上下文反馈谁给——是单元测试、人工 review还是另一个 Agent评估器有没有盲区副作用怎么挡——有副作用的动作要不要 dry-run怎么隔离怎么回滚这些问题不时髦但很实际。一个 Agent 系统开始变稳常常发生在环境开始说真话之后。写到这我想给一个特别务实的建议不要一上来就追求「全自动环境生成」「统一环境接口」「Environment-as-a-Service」。那些东西听起来很酷但离你太远。先做一个小环境契约。选一个你们团队里高频、低风险、可验证的流程。比如 CI 失败分流、文档漂移检查、依赖升级预检查。写清楚目标是什么能看什么只读能改什么隔离怎么验证测试 人工 review什么时候停预算、轮次、时间经验怎么留轨迹、日志、失败路径这份契约不需要长一页纸就够。但它把 Agent 的「工作世界」讲清楚了。最后回到标题那句话Agent 工程不是造火箭是修水管Prompt 是水龙头Context 是水管Harness 是阀门Loop 是循环系统Self-Harness 是自动检修Environment 是整个供水网络。水龙头再高级如果水管漏水、阀门生锈、水质有毒流出来的水还是不能用。很多团队的问题不在模型多强不在 Prompt 多精。在 Agent 住的环境里状态是假的、反馈是噪的、副作用没人管、失败不留证据。先把环境修老实Agent 才有机会变聪明。参考链接Agentic Environment Engineering for Large Language Models, arXiv:2606.12191EurekAgent: Agent Environment Engineering is All You Need, arXiv:2606.13662Addy Osmani,Loop EngineeringKarpathy,autoresearch
