用 Agent 干活的人，大概率都撞过同一堵墙：同一个任务，今天跑得顺，明天就翻车。你以为是运气问题，于是去调提示词，调来调去，它还是时好时坏。
我最早的状态，就是那种一个人盯着一堆 Agent 干活的小组长。每天给它们派活，盯着它们干，干完检查，不行就打回去重来。Agent 一多，我自己的时间全耗在"盯人"上了。
我花了很长时间才想明白：这不是提示词的问题，是结构的问题。单 Agent 干不好活，是因为你把太多事塞给了它。解法也不是把提示词写得更好，而是拆开、编排、治理。这篇文章就是我这条进化路线的完整记录：从提示词工程，到拆成多 Agent，到静态/动态编排，到模型外的 harness，再到软硬约束治理幻觉。最后你会看到，这套技术路线和管理者的成长路线，其实是同一条路。
一、第一层：提示词工程，单 Agent 的上限
最开始，我和所有人一样，遇到 Agent 干不好活，第一反应是 prompt 没写好。
于是调。把要求写得更细，把约束写得更死，把例子写得更多。Skill 本质上也是提示词的一种，Skill 里加点脚本，本质上也还是提示词的一部分。这些都是第一个层级的东西：提示词工程。
但调来调去，有个问题始终绕不过去。你让它写个代码，然后让它自己检查有没有问题，它发现不了问题。你以为是检查的 prompt 没写清楚，继续调，还是不行。
这里有个根源：大模型的能力是有偏向性的。它训练的数据就是"干活"，不是"审查"。你让它自己干完活自己审查，它就是做不好。这不是你 prompt 写得不好，是它天生就不擅长这个。
到这一步我意识到：继续堆提示词，边际收益越来越低。单 Agent 的能力是有天花板的，提示词只能在地基层面做文章。它能注入知识、约束风格，但它给不了记忆，给不了事实校验，给不了流程保证。想突破，必须换结构。
二、第二层：拆成两个 Agent，写审分离
既然它自己干不好"干活+审查"这两件事，那为什么不拆开？一个专门写，一个专门审。
这个想法朴素得近乎废话，但效果立竿见影。写稿的 Agent 只管写，审稿的 Agent 只管挑毛病，角色单一，职责清晰。让一个 Agent 既写又审，等于让运动员当裁判，它天然做不到客观。
拆开之后还能继续拆。能拆两个，就能拆更多。顺着这个思路，编排的原则也慢慢清晰：最好交叉验证，互相写、互相验。串行跑完再并行跑，从不同角度看待同一个问题，这就进入了 Agent 编排的范畴。
但拆完你就发现一个新问题：Agent 变多了，谁来管流程？谁先干谁后干？谁的结果给谁？谁来判断结果合不合格？以前一个人盯一个 Agent，现在你盯不过来。编排的需求就这么冒出来了。
三、第三层：静态编排，然后是动态编排
编排是接住多 Agent 复杂度的骨架。
最简单的是静态编排：固定的流程，先写后审，写完了必须审，审完了才能进下一步。流程稳定的时候，静态编排完全够用。
复杂一点的是动态编排：条件分支，按需路由，根据中间结果决定下一步走哪条路。串行几个 Agent，中间能不能并行？从不同角度同时看一个问题？复杂到一定程度，编排就变成一张 DAG。
这里有个现实问题：这么复杂的编排，谁来做？
模型厂商在做。Kimi 很早就说要搞 Agent 集群、蜂群式干活，把编排能力往模型内部吸收；Claude 的 Dynamic Workflow 也是动态编排的方向。厂商有能力把编排塞进模型里，因为基座模型是他们训的，他们可以把 prompt、skill、多 Agent 编排一点一点吸收进模型内部。
普通人或者企业做不了这件事，我们没法训基座模型。那我们能做的就是：不依赖模型内的编排能力，在模型外面自己套一套编排。这套编排，静态的动态的都能做。
但这里有个关键区别。模型厂商的编排，一次会话结束，上下文就没了，它的训练过程也是一次性的，一个流程从头跑到尾，跑完就散。而我们自己在外面套的这套东西，可以不是一次会话的模式，而是多轮会话，加上长远记忆。这就是下一层要做的事。
四、第四层：harness，模型外的记忆、规则、资讯
把记忆、规则、资讯放在模型外面，按需接进来，这套东西我习惯叫它 harness。就是在模型之外加一套基础设施，把模型不擅长的事接住。
具体接三块：记忆、规则、资讯。
记忆是历史经验。它踩过的坑、做对过的事，不用每次重新教。规则是约束。做什么和不做什么，一定要做什么，一定不做什么，做 A 比做 B 好，这些倾向性写清楚。资讯是模型外的额外信息，实时的事实，它训练时不知道的东西。
整个过程就变成：我拿到额外的信息，或者是记忆，或者是资讯，我知道我有倾向性要做什么，也有倾向性不能做什么，然后让 Agent 带着这些去执行。
为什么放模型外而不是模型内？因为模型外的东西可更新、可追溯、不占上下文，而且不会被模型的幻觉污染。你今天改一条规则，它下次执行立刻生效，不用等重训。你今天喂一条新资讯，它马上就能用上。
有了记忆、规则、资讯，Agent 不用再每次从零开始。但还有一个老大难问题没解决：大模型幻觉重，它会一本正经地胡说八道。编排解决流程，治理才能解决乱来。
五、幻觉治理：软约束加硬约束门禁
治理幻觉，我的做法是给它来点硬的。
Skill 这些东西是软约束。它把规则写进技能里，引导 Agent 的行为。但软约束靠自觉，Agent 状态不好就忽略你。
Skill 里的脚本是硬约束。脚本的结果是确定性的，是代码层面的。Prompt 层面的不确定性，会被代码层面的确定性绑住。你要做的，就是在工作流的各个环节绑上确定性的门禁：你在这个节点提交东西，必须满足我定的条件，不满足就给你打回。这约束了它的提交物是什么。
但门禁约束不了它怎么提交、用什么方式提交。怎么优化这个？靠自净化。
人学习的过程中会被打回。被打回这个行为本身就是一条经验，可以累积到它的知识里，变成"该做什么、不该做什么"的新规则。Agent 也一样：被打回一次，沉淀一条规则，下次就不犯。约束、执行、打回、沉淀，一个治理闭环，而且越用越准。
这套东西不是纸上谈兵，我是真的踩过坑，而且踩得特别深。下面这三个坑，我前后花了可能好几个月才重构完，比想象中久很多。
六、实战三坑：从能跑到跑稳
为了搭一个研发总监 Agent，我开始引入工作流。工作流刚上线那阵，千疮百孔。总结下来有三个大坑。
坑一：鉴权混乱，身份互相串。
现象：多个 Agent 一起干活，每个人互相用错了对方的身份信息。A 提交的东西，记录在 B 名下；B 干的事，锅算在 A 头上。你根本不知道一条记录到底是谁干的。
假设：是不是 Agent 太笨，分不清自己是谁？
排查：每个平台各搞一套身份，Agent 之间没有统一的权限边界，谁是谁根本分不清。不是它笨，是压根没有一套统一的身份体系给它用。
根因：没有统一鉴权，角色没有分离。
重构：打通鉴权。做了很多个平台，每个平台共用同一套鉴权系统，大家制定 OKR，尽可能复用到工作流里。原则就一条：身份不要混用。不过说实话，现在还有一点点问题，我还在想更高级的根治办法。
坑二：门禁形同虚设，只能靠求。
现象：Agent 说提交了，实际上没提交。你只能在 Skill 里跟它说，求求你一定要提交。再后来，在工作流里卡住它，不提交就不给往前推。
但这套门禁写得特别麻烦，是代码 Hack 写在那里的。每改一个工作流环节，就要改一遍代码。门禁系统本身成了最大的坑。
排查：门禁的逻辑散落在工作流代码里，跟具体环节耦合在一起。
根因：门禁和业务逻辑耦合在代码里，不可维护。你加一个环节，就要写一遍新的门禁代码；改一个字段，就要改一遍校验逻辑。
重构：把门禁从代码里拆出来，变成数据库字段。原本写在代码里的"你这个阶段提交要带什么字段"，变成放在数据库里，数据库可以随时 update。代码层面只做一件事：检查数据库的这个字段。这样门禁是动态更新的，也不会污染代码架构。这个阶段搞定之后，门禁系统才算真正完成。
坑三：无法追溯，错了不知道为啥。
现象：它往前推进了，但你不知道为什么能推进；它被打回了，又不知道为什么被打回。中间没有监控，根本没法追溯。
排查：整个流程没有过程记录，每一步发生了什么，没有任何痕迹。
根因：没有流水账。你不知道它干了什么，自然没法判断它对在哪、错在哪。
重构：查工作流流水账。整个任务的流水账信息都在，有了它，就能检查 Agent 哪里做对了、哪里做错了。
本来我只是想解决追溯问题，结果这个功能引申出另一个特别好用的东西：既然有了完整历史，那出问题的时候，可以把整个工作流历史捞出来，发个帖，让几个 Agent 一起商量怎么优化。以前是一个群配一个 Agent，没法让多个 Agent 在一个群里互相商量；现在开了个论坛，大家有问题就去发帖，把相关角色拉进来讨论。哪个环节老出错，把流水账贴出来，大家讨论完，把经验攒成新的 Skill 和规则。这就变成了一个自进化的过程。
顺带说一句，这轮重构还有一个副产品：工作流从一个研发专用的工作流，变成了一个通用的工作流。以前每个业务场景一套流程，现在一套通用流程，配置不同的节点和门禁就能跑不同的业务。
七、管理视角：从亲自教到工作流教
有了这套东西之后，我发现自己从小组长升级成了中层干部。
之前是小组长模式：每天跟 Agent 说，你这里对了，那里错了，这里再改改。这本质上是人肉版提示词工程，手把手教，一个 Agent 一个 Agent 地教，累且不可复制。
现在是中层干部模式：告诉它一个输入，告诉它一个输出，让它自己走一遍流程。走完了我再跟它说哪里对哪里错，让它带着整个工作流一起迭代。我只定工作流怎么设计，只关注事情的输入到输出对不对，不再介入每一个具体环节怎么做。
写稿、审稿这些事，以前是两个 Agent 互相聊，现在是在工作流里进行：写了之后审，审了之后打回，打回之后互相唤醒继续改。我只是把工作流定好，剩下的它们自己跑闭环。
这个转变的洞察是：经验沉淀进工作流，组织能力才不随人走。你亲自教，教出来的东西都在你的脑子里，换个任务又要重新教。你把经验写进工作流、写进门禁、写进规则，这套系统就能自己运转、自己进化。管理与编排是同构的：从亲自干，到搭系统干。
八、收尾：记录、复盘、进化
回头看整个链路：提示词是地基，多 Agent 拆出质量，静态/动态编排接住复杂度，harness 提供模型外的记忆、规则、资讯，软硬约束门禁治理幻觉，被打回的经验沉淀成新规则，记录、复盘、进化，一个完整的闭环。
这条链路上，记录是最容易被低估的一环。进化的前提是观测：你得先发现这是个问题，才能去改进。没有流水账，你连它错在哪都不知道，复盘就无从谈起。所以角色分离、记录过程、复盘进化，这三步是一体的，缺了记录，后面全是空谈。
这背后其实是我在搭建基建：把 Agent 改造成能跑长程任务的模式，把数据整理成适合 Agent 阅读的模式。我们原本的数据组织形式，不支持 Agent 的长程工作，要改造，加工具，让它适应。这算是我摸索下来最花时间的一块。
过程中还有几个认知更新。
一个是：企业知识不是瓶颈。我以前觉得整理知识是瓶颈，现在觉得工作流搭好了，只要提供足够多的 good case 和 bad case，丢给它按工作流自己梳理就行。为什么相信可行？因为只要把流程拆得足够细，每一步从 n 到 n+1，大模型是能做到的。拆得够细，整个流程它都能跑下来。
另一个是：隐性知识最难。它改完代码，架构会不会乱？符不符合我们的使用方法？这种原则性的问题，模型自己判断不了，需要你额外注入。显性知识可以写进规则，隐性知识只能靠它拿着案例不断摸索，你负责纠正。
还有一个：评估系统要跟上。当大家已经开始循环跑起来，你要做的是共建评估系统。构建评估系统，你才能知道它们做得对不对，才能反馈给它们。它们要知道自己犯了错，能看到历史记录，才能改进。什么是错的，什么是对的，整个过程是怎么样，讲清楚，它们就能自己去改进。
至于 Agent 擅长什么？它最擅长的，是在你明确了 Validation 的情况下，穷举各种答案去探索最优路径。但前提是，你给的约束和 Validation 是可靠的。所以我接下来日常要做的，就是构建合适的验证方法，让所有东西都处于可验证的状态，构建一个适合 Agent 运行的环境。它不擅长什么，我们就给它补上；它擅长什么，就发挥它的优势。
我现在做的还是静态编排，但后续肯定会考虑往动态编排走。单 Agent 的瓶颈，是系统设计的起点。