Agent 工程的演进轨迹本质上是系统边界不断外移的过程从如何表达指令到如何构建一个能让 Agent 持续进化的可信世界。Agent 工程的演进轨迹本质上是系统边界不断外移的过程从如何表达指令到如何构建一个能让 Agent 持续进化的可信世界。一、范式转移为什么写好 Prompt不再是核心竞争力去年此时我花大量时间研究如何让 Claude减 少幻觉、提升代码质量。角色设定、Few-shot 示例、Chain-of-Thought、结构化输出每掌握一项技巧产出就提升一截。但今年我几乎不再讨论 Prompt。不是 Prompt 不重要而是真正制约 Agent 能力的瓶颈已经从表达层转移到了基础设施层。当你发现同一个 Prompt 今天有效、明天失效同一个模型在这个项目里表现优异、在另一个项目里频频出错时问题的根源早已不在提示词本身。Agent 工程的焦点正在经历一场系统性外移阶段核心问题系统边界Prompt怎么说清楚单次交互Context该给它看什么会话窗口Harness怎么跑起来运行时框架Loop怎么持续推进工作流编排Self-Harness失败后如何自我修正元认知层Environment在哪里学习和验证可信世界每一层都不是替代上一层而是在追问上一层依赖的事实源可靠吗二、第一阶段Prompt 工程表达层的精细化Prompt 工程解决的是单次交互中如何准确传达意图。这是大多数开发者接触 Agent 的第一站通过角色设定、思维链引导、输出格式约束让模型在特定场景下生成可用结果。在简单任务和标准化场景中Prompt 工程确实能带来显著收益。但天花板很快显现上下文漂移项目背景变化但 Prompt 是静态的无法感知技术栈演进、架构决策变更、团队规范更新跨会话失忆每次对话都是独立的昨天的纠正、上周的踩坑经验不会自动继承局部最优Prompt 优化的是这一步的输出质量但工程实践是连续一万步的决策链Prompt 工程是 Agent 能力的必要非充分条件。它解决的是表达问题但工程问题的本质是状态管理和长期一致性。三、第二阶段Context 工程记忆层的结构化当Prompt无法承载项目全貌时自然转向Context工程通过CLAUDE.md、项目文档、代码摘要、历史对话等构建外部记忆。Context 工程确实解决了Agent不知道项目规范的问题。当 Agent 了解到我们使用 Java 21 Spring Boot 3.4 构造器注入 DTO 隔离时生成的代码终于能通过 Code Review。但 Context 工程引入了新问题窗口瓶颈上下文长度有限塞入20个文件Agent 可能只记住最后5个。关键信息被淹没在噪声中静态快照Context 是手动维护的切片昨天的接口方案、上周的架构决策、上个月的踩坑记录不会自动出现在今天的对话中维护成本随着项目演进Context 需要持续更新漏更新一次Agent 就会基于过时假设做决策Context 工程解决的是这一步该给它看什么但看的内容不会自己更新更新的成本又由人承担。四、第三阶段Harness 工程运行时的约束框架Harness 是给 Agent 套上的运行时框架工具调用规范、权限边界、状态持久化、失败重试策略、终止条件。有了 HarnessAgent 不再是裸奔状态。它有工具箱了有安全边界了有日志和 Trace 了。你可以放心让它执行批量重构、生成测试、检查代码风格等自动化任务。但 Harness 的局限在于它只解决怎么跑不解决跑完之后学到了什么。运行一段时间后你会发现一个反直觉的现象Agent 越跑越蠢。不是模型变弱了而是它一直在同一个环境里打转学不到新东西。它修了一个 Bug下次遇到类似问题还是从头摸索它优化了一段代码但不知道这段优化在真实环境中是否有副作用它完成了一个任务但经验没有沉淀为可复用的知识。Harness 让 Agent 从一次性工具升级为可重复运行的 Worker但没有解决知识积累和进化的问题。五、第四阶段Loop 工程持续运行的闭环机制Loop 工程是让 Agent 能够持续运转修完一个 Bug 自动寻找下一个写完一个功能自动运行测试测试失败自动重试甚至自动开分支、提 PR。Loop 将 Agent 从按需调用转变为长期驻留的自动化实体。它可以处理批量 PR、聚类用户反馈、持续重构代码库。但 Loop 的危险在于没有停止条件的循环就是无限循环。我见过 Agent 在一个文件上反复修改改完 A 破坏 B修完 B 又破坏 A折腾20轮还在原地打转。更隐蔽的风险是如果反馈信号不可靠Agent 会围绕噪声做优化越跑越偏今天修好了明天又坏了但它把噪声当成了规律写进了经验。Loop 工程解决的是怎么持续跑但跑的方向对不对取决于它看到的世界是否在说真话。六、第五阶段Self-Harness 工程元认知层的自我进化当 Loop 跑起来后下一个问题自然浮现Agent 能不能在失败中总结经验能不能在踩坑后记住教训能不能在运行多轮后优化自己的 Harness这就是 Self-Harness 的核心将轨迹Trajectory、证据Evidence、回归测试、Harness 版本都纳入循环让 Agent 在失败中长记性。但 Self-Harness 有一个不可妥协的前提失败必须是真实的经验必须是可验证的。如果 Agent 以为自己修好了但实际上只是测试没覆盖到失败路径那它学到的经验就是错误的。错误的经验写入长期记忆下次还会再犯而且因为有经验反而更自信地犯错。Self-Harness 解决的是失败后如何改一点自己但改得对不对取决于它面对的世界是否在说真话。七、第六阶段Environment 工程可信世界的构建走到这里我终于意识到真正卡住 Agent 的是它居住的世界。不是模型不够强不是 Harness 不够细不是 Loop 不够快。是 Agent 行动之后它所在的环境能不能给出可靠、可验证、可重复的反馈。同一个 Agent同一套 Harness放进三种不同的环境里会长成三种完全不同的行为环境 AAgent 只能读日志不能跑测试 → 它可能写一段看起来合理的解释实际上没修环境 B能跑测试但测试本身不稳定 → 它可能围绕噪声做优化今天修好明天又坏环境 C有隔离 worktree、可重复测试、清晰的失败日志、提交前检查 → 它才有机会把看起来修好了变成证据显示修好了Environment 工程要回答五个核心问题1. 状态在哪里StateAgent 能观察到什么观察到的状态是否真实、完整、及时2. 动作有哪些ActionAgent 能执行什么操作哪些操作有副作用副作用如何隔离和回滚3. 观察如何回流Observation命令输出、测试报告、系统日志、截图如何结构化地进入 Agent 的上下文4. 反馈由谁给出Reward/Eval是单元测试、集成测试、人工 Review还是另一个 Agent评估器有没有盲区评估标准是否稳定5. 副作用如何隔离Sandbox有副作用的操作是否需要 Dry-run如何建立隔离环境如何快速回滚这些问题不时髦但很实际。一个 Agent 系统开始变稳往往发生在环境开始说真话之后。八、务实的落地建议从环境契约开始不要一上来就追求全自动环境生成统一环境接口Environment-as-a-Service。那些听起来很酷但离你太远。先做一个小环境契约。选一个你们团队里高频、低风险、可验证的流程。比如CI 失败自动分流文档漂移检查依赖升级预检查代码风格批量修正然后写清楚维度契约内容目标这个 Agent 要解决什么具体问题成功标准是什么只读范围Agent 能看什么不能看什么防止信息过载和敏感数据泄露可写范围Agent 能改什么在哪里改隔离工作区、分支策略验证方式如何证明它做对了测试 人工 Review 的混合验证停止条件什么时候停预算上限、轮次上限、时间上限经验沉淀轨迹、日志、失败路径如何保存如何用于下一次迭代这份契约不需要长一页纸就够。但它把 Agent 的工作世界讲清楚了。九、一个比喻Agent 工程不是造火箭是修水管Prompt 是水龙头Context 是水管Harness 是阀门Loop 是循环系统Self-Harness 是自动检修Environment 是整个供水网络。水龙头再高级如果水管漏水、阀门生锈、水质有毒流出来的水还是不能用。很多团队的问题不在模型多强不在 Prompt 多精。在 Agent 住的环境里状态是假的过时的代码库、未同步的文档反馈是噪的不稳定的测试、模糊的评估标准副作用没人管直接改主分支、无隔离的执行失败不留证据没有日志、没有轨迹、无法复盘先把环境修老实Agent 才有机会变聪明。