别再把 22 条 Agent Hack 当技巧清单了：一条能落地的 Agentic Engineering 演进路线

别再把 22 条 Agent Hack 当技巧清单了：一条能落地的 Agentic Engineering 演进路线团队把 AI 编码工具接进研发流程后，第一阶段通常都很兴奋：写样例更快了，改脚本更快了，查资料也更快了。问题出在第二阶段。需求开始跨模块、跨服务、跨环境，AI 还是能持续输出内容，但系统开始出现三种更贵的问题：同一个需求在不同会话里反复解释，计划越来越长，结论却越来越不稳定。多个 Agent 同时改仓库时互相覆盖，谁该先动、谁该停下来等审批，没有统一规则。人已经看出方向偏了，但反馈只能停留在聊天窗口，没法稳定进入下一轮执行。这不是模型能力问题，而是工程系统还停留在“单轮对话工具”阶段。Matt Van Horn 那 22 条 Hack 的价值，不在于提供了 22 个小技巧，而在于它们共同指向一个更严肃的结论：当 AI 参与真实研发时，你需要的不是更长的上下文，而是一套能够管理计划、执行、知识和权限的控制面。如果把这 22 条建议都拆开看，很容易变成“语音输入也不错”“多开几个窗口也不错”“把笔记接进 RAG 也不错”。真正有用的读法，是把它们还原成一条系统演进路径。问题不在于 Agent 会不会写代码，而在于系统有没有状态很多团队一开始默认的架构其实很简单：人 - 聊天窗口 - Agent - 代码输出这个链路在写单文件脚本、生成接口样板、补测试用例时完全够用，因为需求范围小，状态主要还在人的脑子里。问题一旦变成跨文件改造，隐含状态就会迅速膨胀：当前任务真正要解决的问题是什么。哪些文件允许改，哪些文件只能建议不能自动写。哪些历史决策必须继承，哪些旧方案已经失效。哪些反馈只是措辞修改，哪些反馈意味着方案方向错误。如果这些状态都寄存在会话上下文里，系统会很快出现两个现象。第一，状态不可重入。上下文一旦爆掉、会话一旦中断，新会话只能靠人工重新解释，Agent 无法确定之前已经完成到哪一步。第二，状态不可治理。你没法为“正在执行的计划”设置门禁，也没法审计“这个改动为什么发生”。这正是很多团队觉得 AI 能写代码，却很难把它放进正式流程的根因。所以，Agentic Engineering 的起点不是多 Agent，而是把状态从对话里拿出来。第一层先做计划控制面，plan.md不是文档，而是状态机入口原文里最关键的一条 Hack 是“有想法就先/ce-plan，生成plan.md”。如果只把它理解成“先写计划再干活”，那就低估了这一步的工程意义。在生产环境里，plan.md至少承担四个职责：任务快照：把目标、范围、约束、涉及文件和验收标准持久化下来。执行入口：执行 Agent 不必依赖整段历史对话，而是围绕计划文本开展工作。审批载体：高风险改动可以对计划本身做审查，而不是等代码写完再追溯。恢复锚点：上下文丢失或会话切换时，新 Agent 可以直接从计划恢复。它更像一个轻量状态机，而不是传统意义上的文档。计划一旦生成，后续动作都不再是“继续聊”，而是“围绕一个外部化状态继续推进”。一