从炫技到落地：Agent 工程化上线的 12 条关键经验
从炫技到落地：Agent 工程化上线的 12 条关键经验
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, 记忆系统, 办公效率, 网络安全, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/KJVL18P8P6lOYdhiL67yhw
摘要
大家好，我是悟鸣。 这两年，Agent 圈子里有一种很常见的错觉。 很多系统在演示阶段都特别亮眼，任务一跑，效果惊艳，团队也会很快进入兴奋状态。可一旦真的接进真实业务，问题就开始一个接一个冒出来。今天跑偏，明天失控，后天又因为上下文污染、流程混乱或者经验没有沉淀，变得越来越难维护。 很多人第一反应会把原因归到模型、Prompt 或工具链上。可如果把观察周期拉长一点，你会发现，真正决定一个 Agent 系统能不能长期稳定运行的，往往是背后的工程约束。 最近我看到一套很有启发的方法论，叫 12-Factor AgentOps。 网站地址：https://www.12factora...
核心内容
大家好，我是悟鸣。
这两年，Agent 圈子里有一种很常见的错觉。
很多系统在演示阶段都特别亮眼，任务一跑，效果惊艳，团队也会很快进入兴奋状态。可一旦真的接进真实业务，问题就开始一个接一个冒出来。今天跑偏，明天失控，后天又因为上下文污染、流程混乱或者经验没有沉淀，变得越来越难维护。
很多人第一反应会把原因归到模型、Prompt 或工具链上。可如果把观察周期拉长一点，你会发现，真正决定一个 Agent 系统能不能长期稳定运行的，往往是背后的工程约束。
最近我看到一套很有启发的方法论，叫 12-Factor AgentOps。
网站地址：https://www.12factoragentops.com/
它讨论的重点，是当 Agent 真的进入生产环境之后，你要靠什么让它持续、稳定、可控地工作。
如果你正在做 AI Coding、Agent 工作流，或者想把一个能跑的原型推进成能上线的系统，这 12 条原则很值得认真过一遍。
这套方法论到底在讲什么
12-Factor AgentOps 的核心判断很简单：一个能长期跑下去的 Agent 系统，必须同时建立三种纪律。
- 上下文纪律：控制 Agent 在每一步究竟看到什么，不让它默认吞下全部信息
- 知识纪律：把每次会话里的经验提取出来、验证清楚，再回流到后续会话中
-
流程纪律：用外部验证、单向推进和层级监督，保证系统质量不会一路滑坡
如果按适用范围来看，这 12 条原则又分成两层。 -
Factor I 到 IX 更适合单 Agent 场景
- Factor X 到 XII 面向多 Agent 并行和编排场景
换句话说，这套方法论真正提醒我们的，是一件很容易被忽略的事：
Agent 不是一个更聪明的脚本，它本质上是一套需要被治理的生产系统。
十二条原则
I. Context Is Everything｜上下文即一切
很多人对上下文窗口有个误解，觉得只要窗口足够大，就可以不断往里塞信息。
现实并不是这样。LLM 并不会像数据库那样稳定记住所有内容。它对开头和结尾通常更敏感，中间信息更容易被忽略。所以，进入上下文窗口的内容，本身就应该被当作一种稀缺资源来管理。
这条原则背后的核心动作有三个。
- 只在当前步骤加载真正需要的上下文
- 在阶段切换时主动做压缩，用摘要替代整段原始对话
- 尽量把上下文利用率控制在窗口上限的 40% 以内
很多 Agent 后面越跑越乱，问题不一定出在能力不够，很可能只是上下文已经失控了。
II. Track Everything in Git｜一切纳入 Git
这里说的“一切”，真的不是一句口号。
除了代码，Issue、决策记录、经验教训、会话产物、Agent 交接笔记，都应该尽量进入 Git。因为 Git 天然提供了版本历史、差异对比、协作能力和审计线索，而且没有额外依赖。
判断这条原则有没有做到位，有一个很直观的标准：
如果一个新 Agent 只靠一次 git clone，就能把项目的工作上下文基本恢复出来，那你的系统就已经足够健康了。
反过来看，如果状态散落在 Jira、Notion、聊天记录、向量数据库等多个地方，Agent 每次启动都要重新拼上下文，整个系统的维护成本只会越来越高。
III. One Agent, One Job｜一 Agent 一任务
每个 Agent 都应该只做一件边界清晰的事，并且使用新的上下文窗口。
这一点听起来简单，真正落地时却很容易偷懒。比如一个 Agent 刚做完代码研究，团队往往会顺手让它继续实现。问题在于，这时候它的窗口里已经塞满了研究上下文，继续写实现，反而更容易偏。
更稳妥的做法是，阶段一结束就停下来，把研究结果蒸馏成摘要，再启动新的 Agent 继续往下走。
Worker 级 Agent 只处理单个 Issue，至于批量协调、任务编排和资源分配，应该交给更上层的编排系统。
IV. Research Before You Build｜先研究，再动手
很多返工，问题往往不在写得慢，而在一开始就写偏了。
所以这条原则强调，每次实现之前，都应该先有一个独立的研究阶段。跳过研究，Agent 很容易写出那种看起来没问题、实际上和代码库完全不贴合的代码。它可能重复已有工具，违背既有架构决策，也可能直接撞上项目约定。
研究阶段最理想的产物，是一份结构化的发现文档。后面的实现，应该建立在这份输入之上。
前面多花 10 分钟研究，后面往往能少掉几小时返工。这个账其实很划算。
V. Validate Externally｜外部验证
Agent 不能自己验证自己，这件事最好在系统层面写死。
同一个上下文里生成了代码，再让同一个上下文回头审查这段代码，本质上还是在放大确认偏误。真正有效的验证，必须来自外部。
这个“外部”可以是不同 Agent、不同模型、自动化测试套件，或者人类专家。安全、架构、法律这类高风险决策，更应该明确保留人工介入。
测试之所以重要，是因为它不关心你的主观意图，只关心最终行为是不是满足断言。对 Agent 来说，这种验证方式最干净，也最不讲情面。
VI. Lock Progress Forward｜让进度只能向前
通过验证的工作，应该被锁住，不能随意退回去。
这里讲的是一种棘轮机制。Agent 可以在前面阶段自由探索，也可以并行尝试不同方案，但只有那些已经通过验证的结果，才能进入主线。
受保护的主分支、Issue 状态锁、完成账本，这些东西合在一起，才能把系统变成单向推进的结构。
同时还要给失败设置预算。达到上限之后，就应该升级处理，而不是让 Agent 一直在原地打转。
Agent 的试错成本其实不高，真正昂贵的是人的时间。棘轮机制的意义，就是把混乱搜索变成有效推进。
VII. Extract Learnings｜提取经验
一次会话结束后，留下来的不该只有工作产物，还应该有经验教训。
很多团队只盯着结果文件，却默认让过程里的判断、失败和坑点随着会话一起消失。这样做的代价，就是同样的问题会被反复踩。
值得提取的东西包括这些。
- 做了什么决策，为什么这样做
- 哪些方法试过了，但行不通
- 过程中识别出了什么模式
- 集成时踩到了哪些坑
经验一定要结构化、可打标签、可搜索。只要这一步能做好，短短几分钟的整理，后面往往能省下几小时重复劳动。
VIII. Compound Knowledge｜让知识产生复利
提取经验只是第一步，更关键的是把它重新送回系统里。
12-Factor AgentOps 提到一个很重要的闭环：提取、质量门控、存储、会话启动时注入、引用追踪与衰减。
也就是说，经验不能只是被存下来，它还要在下一轮任务启动时真正被用上。如果只是放进仓库里，从来没有被引用，那它就还没有形成组织能力。
原文里给了一个很有意思的判断式：
检索率 × 引用率 > 衰减率
只要这个关系成立，后面的会话质量就会逐步高于前面的会话。长期来看，这种组织记忆，才
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充