从执行者到管理者：Agent 开发带来的思维转变
Viewed: loading...
13 minutes to read
过去做软件工程时，我有一套很自然的工作习惯：
遇到复杂任务，先理解问题，再拆解步骤，定义边界，补上异常处理，最后通过自动化和工程化，让整个系统稳定运行。
这套方法在传统软件工程里很有效。我也一直以为，复杂问题就该这样解决。
直到最近，我开始做一个跨端迁移的 AI Agent 项目。
我们有一个 iOS App，需要把里面的一批业务页面迁移到 React Native。简单说，就是换一种技术重新实现这些页面，同时尽量保持原来的功能和外观。不同的是，这一次真正执行迁移工作的，不只是工程师，还有能够读代码、使用工具、运行程序并自行修改结果的 AI Agent。
我慢慢发现：当执行者从人变成 Agent，而我们对任务的了解又很少时，过去那套熟练的工程方法，反而可能成为限制。
真正需要改变的，不只是 Prompt 怎么写、工作流怎么画，而是我在整个系统里的位置。
我得从一个亲自设计并控制每一步的执行者，变成一个管理目标、观察结果、寻找关键节点的人。
这很像工程师第一次成为管理者。
一个看起来很专业的错误
项目刚开始时，我很自然地把迁移过程拆成了四层：
- 先迁移独立组件；
- 再迁移完整页面；
- 然后组合业务模块；
- 最后推进整个项目。
每一层又有输入、执行、验证、修复、完成条件和失败后的退出条件。
为了让 Agent 更稳定，我继续给这套体系加东西：迁移技能、验收标准、组件实验室、视觉对比、调试工具、构建工具、任务清单、知识索引……
从软件架构的角度看，它越来越完整。每个环节都有名字，每个风险都有对应的机制，流程图也越来越漂亮。
问题恰恰出在这里。
它太完整了。完整到让我产生了一种错觉：我已经理解这个问题，现在只要把它工程化就可以了。
可事实上，我们真正知道的事情非常少。
我们甚至还没有回答一个最基本的问题：
如果只给目标、工具和验收标准，一个足够强的 Agent，自己到底能不能迁完一个页面？
这个问题没有答案，我却已经替它设计好了从组件到项目的完整组织结构。
后来回头看，我不是在解决已经发生的问题，而是在用架构填补未知。架构越完整，我越有安全感；但那份安全感不是来自事实，而是来自“所有东西都有名字”。
不要替执行者完成所有思考
最开始，我把 Agent 当成一种更聪明的程序。
普通程序需要明确指令，Agent 当然也应该有一套正确流程：
第一步，分析原生页面；第二步，整理组件；第三步，生成代码；第四步，运行验证；第五步，根据结果修改。
这听起来完全合理。后来老板提醒我：
不要急着告诉 Agent 第一步做什么、第二步做什么。给它目标和验收标准，让它自己决定怎么完成。
这句话一开始很反直觉。工程师接受的训练就是：任务越复杂，越应该拆解。
但任务需要拆解，不代表管理者应该替执行者完成所有拆解。
假设我要让一个高级工程师改造支付系统。我当然应该告诉他最终目标是什么，哪些接口不能破坏，数据不能丢，性能需要达到什么要求。
但如果我进一步规定：上午先读哪个文件，下午先写哪个类，测试必须按照我给出的顺序执行——那我就不是在管理一个高级工程师，而是在把他当成一段执行脚本。
Agent 也是如此。它和普通程序一个很大的区别，就是可以根据眼前的信息选择下一步。如果我提前把每个动作都写死，可能反而拿走了它最有价值的能力。
当然，这个类比有边界。Agent 不是人，也不会承担人的责任。涉及资金、隐私、线上数据和不可逆操作时，权限、审批和固定流程仍然必不可少；步骤已经非常稳定的任务，也可能更适合传统工作流。
但我们面对的是一个结果可以验证、失败可以回滚、解法仍不明确的探索任务。此时过早规定路径，很可能只是把我的猜测写进系统。
Prompt 为什么会变成员工手册
一旦把 Agent 当成员工看，很多问题突然变得很熟悉。
假设一个员工第一次填文档时漏了一个字段。正常的管理者大概会提醒他，看看这是偶然疏忽，还是文档本身设计得不清楚。
他通常不会第二天立刻发布一份新制度：
《所有员工填写文档前必须执行字段完整性检查规范 V1》
但在 Agent 开发里，我们非常容易这么做。
Agent 漏了一个组件，于是 Prompt 里加一句：“开始迁移前，必须列出所有组件。”
Agent 又漏了一个页面状态，再加一句：“必须遍历所有状态。”
视觉有问题，增加一套视觉检查技能。构建有问题，再增加一套构建技能。
每次事故都对应一条新规则。很快，Prompt 和 Skills 就变成了一本厚厚的员工手册。
旧问题也许少了一些，但整个系统越来越慢，规则之间还可能彼此冲突。最重要的是，Agent 逐渐失去了自主解决新问题的空间。
这和组织官僚化的过程很像：每发生一次事故，就增加一条制度。几年以后，没有人记得某条制度为什么存在，但每个人都要继续执行。
这并不意味着 Agent 不需要规则。就像公司不能没有制度一样，有些边界必须从第一天就明确：
- 不能为了方便而删除原有功能；
- 不能擅自改变产品行为；
- 不能修改与任务无关的代码；
- 不能只说“代码写完了”，必须拿出真实运行和验证的结果；
- 能从代码和运行环境里查清的事实，不能靠猜。
这些规则告诉 Agent 什么事情不能发生。
另一类规则却是在告诉它必须怎么做：必须先生成页面结构，必须先拆组件，每个复杂组件都要进入某个实验环境，页面必须依次通过六层检查。
边界是在球场四周画线，流程则是在规定球员每一步怎么跑。真正需要警惕的不是规则本身，而是我们什么时候开始替 Agent 规定跑法。
一次失败，还不是一种规律
这是我最难改变的地方。
传统工程师遇到 Bug 后的本能是：找到原因，修掉，加测试，确保它以后不再出现。
这是很好的习惯。但在探索型 Agent 项目的早期，还有一个问题：你并不知道这次错误是不是规律。
比如某个页面漏掉了一个 Badge，也就是界面角落里的小标记。它可能意味着：
- Agent 普遍无法理解原生页面的完整结构；
- 这个页面刚好比较特殊；
- 这次提供给 Agent 的信息不完整；
- Prompt 里有一句话容易误解；
- 工具没有把关键画面展示出来；
- 或者它只是偶然犯了一次错。
如果第一次出现，就把“必须先生成完整页面结构”写成永久规则，我们其实是在用一个样本定义整个系统。
所以我开始把问题分成三类。
第一类，是实验本身就有问题。比如任务说明里连“保持功能一致”都没写清楚，这当然要马上修。
第二类，是必要能力缺失。比如 Agent 根本看不到 App 运行后的截图，它自然无法判断页面像不像，这也应该马上补工具。
第三类，才是某一次具体的业务失败。它不一定要立刻变成全局规则，可以先记录，再继续运行，看看会不会再次出现。
第一次，记录。第二次，开始怀疑。第三次，寻找共同原因。
这不是统计学定律，只是提醒自己：别让修 Bug 的冲动跑在理解问题前面。
真正值得工程化的问题，通常同时具备几个特点：反复出现、代价很高，而且已经找到相对稳定的解法。
比如连续迁移十个页面，有四个失败，其中三个都因为 Agent 没有理解完整的页面状态。这时我们才得到一个像样的判断：页面理解可能是迁移系统的瓶颈。
接下来可以做实验：给它更多原生截图会不会更好？提供页面结构提取工具有没有帮助？在开始写代码前加一次检查是否有效？
如果修改以后成功率真的提高，这个机制才获得留在系统里的资格。
管理者不是掌握所有节点，而是寻找杠杆点
老板问过我两个很简单的问题：
如果整个过程只能检查一次，你检查哪里？
如果只能检查两次，你把检查点放在哪里？
我一下子不知道怎么回答。
我之前所谓的“全局思考”，是把系统里的所有节点列出来，然后为每个节点建立规则：组件什么时候算完成，页面什么时候算完成，模块什么时候算完成，每一层要经过哪些验收。
每个节点都很重要。结果就是，所有东西都是重点。
但真正的管理不是掌握所有节点，而是找到少数能显著改变结果的地方。
一个 CEO 不会阅读公司的每一个代码改动，不会参加每一场销售会议，也不会审批每一张设计稿。他真正要想的是：看哪几个数字，能判断公司是否健康？参加哪几个会议，最可能改变结果？哪个问题一旦解决，整个系统都会更顺？
放回页面迁移也是一样。
如果大部分返工都来自 Agent 一开始就理解错了页面，那么最值得检查的，是它第一次形成页面理解的时候。
如果页面结构通常没有问题，但最后总要花很久调整颜色、间距和布局，那么真正的杠杆点，可能是第一版页面跑起来后的视觉反馈。
其他步骤当然也存在，但不代表管理者都要插手。
执行者看到一条流程，会问每一步怎样保证正确。管理者先看最终失败发生在哪里，再向上寻找哪个变量贡献最大。
这两种思维不是谁比谁高级，而是负责的对象不同。执行者对动作负责，管理者对整个系统能否持续达到目标负责。
人一旦下场，就看不见 Agent 的真实能力
项目里还有一个让我很不适应的要求：
不要亲自插手具体迁移。
Agent 卡住了，我明明知道怎么解决，为什么不能顺手改一下？
因为只要我每次都下场，最终测出来的就不是 Agent 的能力，而是“我加 Agent”的联合能力。
页面当然可能做成，成功率看起来也可能很高。但真正的问题仍然没有回答：如果把这个 Agent 交给其他人，它还能不能工作？如果从几个页面扩大到几百个页面，它是否仍然成立？
这也像管理团队。
一个经理如果遇到复杂问题就亲自接手，短期绩效可能很好。长期结果却是团队永远离不开他，他也永远不知道团队独立工作的能力到底在哪里。
如果 Agent 每次偏离方向，人都在背后扶一下方向盘，我们最后甚至无法判断：Agent 是真的会开车，还是只是没有撞上墙。
管理者一个很反直觉的能力，就是允许系统暴露真实水平。失败不是为了证明谁不行，而是为了看清哪里真正需要改变。
Harness 应该是工作环境，而不是遥控器
这次思维变化，也改变了我对 Agent Harness 的理解。
Harness 这个词不太好翻译。以前我把它理解成一整套指导 Agent 工作的流程：Prompt、技能、循环、验收标准、任务清单，组合起来像一只遥控器，告诉 Agent 每一步怎么走。
现在我更愿意把它理解成 Agent 的工作环境。
对一个迁移 Agent 来说，这个环境包括代码仓库、构建工具、模拟器、运行日志、网络请求、页面截图、视觉对比、自动测试，以及明确的权限和停止条件。
它们不是在耳边不停指挥：
先往左走三步，再往右走两步。
它们做的是让 Agent 看见现实：
代码有没有编译？页面能不能打开？按钮点下去有没有反应？现在的画面和原来的画面差在哪里？
一个好环境不能保证 Agent 永远做对，却能让它知道自己做错了，并有机会根据真实反馈修正。
管理优秀工程师也是这样。最有价值的往往不是一份写满步骤的操作手册，而是足够的信息、合适的工具、明确的目标和及时的反馈。
架构不再是答案，而是一个等待验证的假设
我最早认为，先做组件、再做页面的 Component Loop，是整个系统天然应该存在的一层。
现在我更愿意把它看成一种假设。
对于某些复杂页面，Agent 可能判断：先把几个独立组件做好，再组合成页面更省力。对于另一些简单页面，它也可能直接整体实现。
与其提前规定，不如先让它跑一些真实样本，再比较结果。
如果“先做组件”让成本增加一半，成功率只提高一点点，这层流程可能根本不值得存在。反过来，如果只增加少量成本，却让成功率明显提升，那时才有证据把它固定下来。
架构应该从真实数据里长出来，而不是从逻辑上的美感里长出来。
所以项目下一阶段的问题，也从“标准迁移流程应该是什么”，变成了：
一个独立的迁移 Agent，到底能做到什么程度？
实验不需要一开始就很复杂。固定任务说明，告诉它目标、不能触碰的边界和什么才算完成；给它完整工具，但不规定具体步骤；然后拿几个难度不同的真实页面去跑。
我们记录它用了多长时间、是否一次成功、最后能否自主完成、人工介入了几次，以及失败发生在哪里。
先看事实，再决定要不要增加流程。
创业早期最危险的，是把错误方向做得太完整
后来我发现，这种思维并不只属于 Agent 开发，它和创业的 0 到 1 很像。
创业早期最大的困难通常不是执行得太慢，而是根本不知道什么东西是对的：谁是真实用户？用户为什么愿意付钱？哪个功能最重要？产品是不是解决了一个真问题？
如果这些问题还没有答案，团队就开始搭完整的客户管理系统、销售体系、运营平台和数据仓库，每个系统都可能设计得很专业。
它们只有一个共同的问题：全部建立在未经验证的假设上。
工程能力越强，有时反而越危险。因为团队可以非常快地把一个错误方向做得很完善。结构一旦建立，又会产生沉没成本：有人开始维护它，有人开始解释它为什么合理，最后甚至会拿框架去解释现实，而不是让现实修改框架。
软件工程里常说“不要过早优化”。探索项目里还有一种同样危险的东西：过早结构化。
事实还没出现，组织结构已经设计好了；失败模式还不知道，操作手册已经写好了；一个 Agent 的真实能力还没测，多 Agent 协作架构已经搭好了。
不是这些设计一定不好，而是它们出现得太早。
从执行者到管理者，失去的是控制感
为什么这个转变这么难？
因为工程化会给人很强的控制感。
当我有流程图、检查表、验收标准、技能和状态机时，我会觉得事情尽在掌握。探索却要求我承认：现在有很多事情不知道；Agent 可能走一条我没有提前设计的路；它甚至可能失败。
这对执行者很不舒服。
执行者的价值感常常来自：“我知道怎样把事情做对。”
管理者的价值却越来越来自：“我知道哪些事情现在不用我做，哪里才值得我插手。”
这不是减少责任，而是提高责任的层级。
过去，人的工作是写代码，让系统运行。现在，Agent 开始成为执行主体，人的职责会逐渐上移：给多少自主权？哪些边界不能碰？在哪里检查最有价值？什么失败值得变成制度？怎样让系统不依赖最懂它的那个人，也能完成任务？
能力也从“我能解决多少问题”，慢慢转向“我能不能选对值得解决的问题”。
不要把未知工程化
传统工程项目优化的是执行效率：怎么更快、更稳地把已经确定的事情做完。
探索项目首先要优化学习速度：怎么尽快知道哪些假设是真的，哪些只是我们想当然。
在这个阶段，合理的顺序应该是：
先给目标和边界，让系统真实运行；允许问题暴露，记录失败；等重复模式出现，再选择值得干预的地方；验证干预真的有效，最后才把它变成 Prompt、工具、检查点或固定流程。
我以前以为，全局思考是把所有事情都考虑到。
现在我开始觉得，面对高度未知的问题，真正的全局思考，是知道什么暂时不需要考虑。
几百个页面以后怎么调度？现在不知道，也不重要。因为我们甚至还没有证明，Agent 能不能稳定地迁完几个页面。
这种“不知道”不是能力不足，而是一种管理纪律：不要用未经验证的设计填满未知。
工程化本身没有错。在确定的问题里，它能放大效率；在未知的问题里，过早工程化只会放大假设。
先让系统运行。
先让真实问题暴露。
先找到少数真正决定成败的地方。
然后再干预，再验证，再工程化。
让规律从现实里长出来，再让规律变成系统。