我一个人管了7个AI员工：从单Agent到多Agent协作的实战之路

不是你会用多少种AI工具，而是你能不能设计一个让AI自主运转的系统。

产生做数字办公室的念头，是从罗振宇十周年发布会开始的。

那天他们发布了"创作专家团"功能，这是一个让AI帮你写稿、排版、做封面的创作工具，年费2999元。我当时的第一个反应不是"这功能真好"，而是"我能不能也做一套类似的东西？"

但这个念头没撑过24小时就被我自己否定了。原因很现实：得到是一家专注知识与创作的公司，他们有十几年的内容数据和创作者行为数据，可以用来调教和验证AI产品的效果。而我做的是更通用的数字办公室和数字员工，面向各个行业、各种工作场景。作为个体和小团队，我根本不可能了解各行各业的实际工作场景和流程，缺乏足够的数据来调教一个通用产品。

所以我换了个思路：先做给自己用。自己就是第一个试验品。

这个逻辑其实不复杂。先做出一个自己能用、用着舒服的东西。我们绝对不是少数人，自己认可的产品，一定也会有许多人认可。真实需要就是最好的产品验证。硅谷做AI硬件的创业者说过类似的话："好的AI硬件都是为创始人自己做的。"当你的产品首先解决的是你自己的真实痛点时，你不需要做用户调研，你自己就是用户，你的痛苦就是需求。

我每天的工作几乎全靠AI完成。不是偶尔用用ChatBot问几个问题的"用"，是真的把AI当员工在用，调研、规划、写文档、画原型、写代码、做汇报PPT，一条龙。半年前我还只有一个Agent（智能体，能自主规划和执行任务的AI系统），靠往里面塞大量skill（技能，Agent可调用的固化能力模块）来硬撑。撑到后来，我终于撑不住了。

最开始我的工作流是这样的：先跟Agent讨论工作计划，告诉它我要做什么、标准是什么，不急着动手，通过一问一答把细节想清楚。然后让它去全网调研，补充数据资料，出一份调研报告。我读完报告再讨论一轮，让它列计划，计划通过后才真正动手做。

听起来很合理，对吧？问题出在执行上。

随着我往Agent里塞的skill越来越多，它的soul.md文档（灵魂文档，Agent启动时强制读取的核心规则文件）越来越长，调用skill的准确度就开始直线下降。一个需要十几个步骤的长流程，Agent经常在中间调错skill，或者干脆跳过某个步骤。你让它做调研，它直接动手写方案了；你让它先规划，它已经开始写代码了。

后来我才想明白：这不是模型能力的问题，而是它的注意力机制崩溃了——它不知道此刻该聚焦于哪一件事。

这不是模型能力的问题，而是它的注意力机制崩溃了——它不知道此刻该聚焦于哪一件事。

在和很多Agent开发者交流后，我发现这并非我一个人的困扰。一位做Agent开发的创业者曾告诉我："Agent在执行时常常会跳步，这与模型本身有很大关系。它可能不会调用你规定的Skill，而是自己拼凑内容来完成任务。"他的解决方法和我后来采用的如出一辙：把核心规则写在soul.md里，而不仅仅是放在Skill层。soul.md是Agent启动时必须强制访问的文档，而Skill层的内容它可以选择性忽略。规则放在不同层级，执行效果天差地别。

这跟人类一样。你让一个人同时担任秘书、研究员、产品经理、设计师和程序员，他一定会顾此失彼，不，他一定会把所有事情都搞砸。人类解决这个问题的方法是分工协作，那么AI为什么不能呢？

这个直觉，其实有一个经典的理论作为支撑

意大利学者M. Dorigo在20世纪90年代通过观察蚂蚁觅食行为，提出了蚁群算法（Ant Colony Optimization）。这个故事很经典，但很少有人深入思考它对AI Agent的启示。

单只蚂蚁的智商极低，它只能做两件事：沿着信息素浓度高的路径前进，以及在自己走过的路上留下信息素。然而，整个蚁群通过释放"信息素"这种化学信号进行间接通信：路径越短，往返越快，信息素积累得就越浓，后续蚂蚁选择这条路径的概率也就越大。这种正反馈机制让整个蚁群无需任何中心调度，就能在蚁穴与食物源之间找到最短路径。

真正的智慧，不在于个体的全能，而在于群体如何通过简单的局部规则，涌现出全局最优解。

"群智能"（Swarm Intelligence）这个概念由Gerardo Beni和王晶在1989年提出，其核心思想是：在去中心化的系统中，个体只遵循简单的局部规则，没有任何单一节点控制全局，但复杂、自适应的群体行为会自然涌现。不需要中心调度，不需要总指挥，只要规则足够简单、信号足够清晰，最优解自己就会浮现。

我的做法，本质上与蚁群的逻辑是同构的。

我按照分工拆解了Agent。每个Agent只专注于一件事，它的soul.md文档也只写它那个角色的职责、工作流程和配合方式。文档变短了，注意力就集中了，调用Skill的准确度也随之恢复。

秘书Agent负责理解我的意图、翻译需求、编排工作流、分发任务和审查成果。研究员Agent负责全网调研与竞品分析。计划Agent负责制定方案和工作计划。写作Agent负责撰写文档。设计Agent负责绘制原型。代码Agent负责实现功能。每个Agent都有自己偏好的模型、专属的技能和明确的职责边界，彼此没有交叉，也没有模糊地带。

没有中心调度者告诉每只蚂蚁该走哪条路，但信息素机制能让最短路径自然浮现。同样，没有全局控制器指挥每个Agent，但秘书Agent负责编排工作流，执行Agent各司其职，最终就能产出可靠的交付成果。

我将默认Agent设为秘书。每次我下达指令，秘书会先理解我的意图，将我的话翻译成具体的需求和目标，并和我确认。确认之后，秘书会根据需求制定工作计划，判断需要哪些Agent参与、按什么顺序执行、交付什么标准，然后给我一份计划让我决策。

我同意之后，任务才会下发到具体的执行Agent。

秘书的角色不是"下命令"，而是"翻译、编排加审查"。

它把我说的自然语言翻译成Agent能理解的任务描述，判断任务需要哪些Agent参与、按什么顺序执行，并在所有Agent交付后，对照原始需求进行质量审查。这个架构相当于把一个项目经理的职能搬到了AI身上，只不过这个项目经理从不请假、不带情绪、永远在岗。

拆分Agent之后，我发现了另一个问题：不同模型的能力差异很大，同一个模型无法胜任所有事。这个发现其实是被迫的——当你只有一个Agent时，自然会希望选择"最强的模型"并把一切交给它。但当你拥有一群Agent时，就会开始观察每个模型到底擅长什么。

这种模型选型不是拍脑袋决定的，而是经过几十个项目的反复测试、对比和替换后，最终收敛出的结果。我总结下来就一条原则：不是选最强的模型去干所有事，而是选最合适的模型去干最合适的事。

这一点跟很多人的直觉相反。市面上流行一种说法叫"模型能力是上限"，认为用一个更强的模型，任务完成率自然就更高。但我的实操经验是：模型的"强"和"合适"是两回事。一个推理能力顶级的模型，可能中文表达生硬；一个中文表达流畅的模型，可能缺乏结构化思维。让一个数学天才去写散文，可能还不如让一个文笔好的普通学生来写，在AI上也是同一个道理。

你可能会问：那你每个月花在模型订阅上的钱到底有多少？说实话，加起来确实不便宜。但比起用一个模型什么都干不好、反复返工所浪费的时间和上下文token（AI处理文本的计算单位），这笔钱花得值。这就像组建一个人类团队时，你不会只招一个"什么都会一点"的全栈工程师，然后让他包揽所有事；你招的是各有所长的专才。AI团队的构建逻辑也是一样的。

典型的工作场景

我们研究所跟不少高校和企业有AI落地方面的合作，所以经常有原型验证的需求。典型的工作场景是这样的：

和合作方开完会，我会把AI录音卡转写下来的文档直接丢给秘书Agent。秘书读取文档，判断这是什么类型的任务——是一个竞品调研需求，还是一个产品原型开发需求？判断完后，秘书会来跟我确认："你这次是要做竞品调研还是原型开发？交付标准是什么？核心指标有哪些？"

我补充完信息后，秘书会编排好工作计划让我拍板。这个计划不是笼统的"你先调研再写方案"，而是非常具体的：研究员用哪几个信源、调研报告要覆盖哪几个维度、计划Agent出方案时是否需要做AB对比、原型要覆盖哪些核心交互路径、最终PPT用哪个模板风格。

我同意之后，研究员Agent会先出动，去网上扫一遍相关信息，包括竞品的功能对比、用户口碑、定价策略，并按照我给它写的规则整理成报告。这个节点会暂停一下，等我判断。调研方向对不对、有没有漏掉关键竞品、数据来源是否可靠，这些判断AI做不了，必须由我来做。

我确认后，计划Agent会接手，将调研结论转化为可执行的工作计划，明确写出时间线、里程碑和交付物标准。接着，写作Agent开始撰写需求文档，设计Agent绘制原型——这不是那种高保真、可直接上线的原型，而是能跑通基本交互流程、可以拿给合作方"点着看"的Demo。原型通过后，再交给代码Agent实现最基础的演示功能。

最终的成果会回到秘书Agent那里。秘书会按照我内置的规则进行审查、评分和反思，并给我出具成果报告。这份报告不只是说明"完成了什么"，还会分析"哪些地方与原始需求有偏差"、"哪些环节的效率可以优化"，并给出建议，例如"建议下一次在XX环节增加门禁检查"。秘书Agent还内置了一套专门用于生成HTML PPT的技能，因此最终交付的不仅是一份文字报告，还有一份可以直接拿去给合作伙伴汇报的PPT。

从会议录音到可演示的原型和汇报PPT，整条链路我只需要在几个关键节点做决策，其余部分都由Agent们自行完成。

从会议录音到可演示的原型和汇报PPT，整条链路我只需要在几个关键节点做决策，其余部分都由Agent们自行完成。

听起来很顺畅，对吧？但其实这条路并非一开始就走通了。

最大的一个坑是Agent输出的"模糊的好"。

三个大坑

传统软件有一个好处：对就是对，错就是错。一个按钮点了没反应就是bug，数据算错了就是错误。但Agent的输出不一样，它每次运行的结果都可能不同，同一个任务跑两遍，可能会给你两个版本，而两个版本"感觉都还行"。问题在于，"感觉还行"这种主观判断根本支撑不了交付。

一个产品原型的交互逻辑偏了几个像素，我可能看不出来。一份需求文档漏掉了一个边界条件，我可能因为读得太快而跳过去了。但这些偏差传导到下游后，设计Agent基于有偏差的需求画了原型，代码Agent基于有偏差的原型写了功能，最后出来的东西跟原始需求可能已经差出一个量级了。

我的解法是给每个生产任务加上质量门禁（Quality Gate），本质上是一个约束框架（harness）。检查不通过，任务就不能标记为完成。

"Harness"这个词最近在AI圈很火。它本意是马鞍或马具，你有一匹千里马（大模型），但只有通过马具（约束和引导）才能驾驭它，让它沿着正确的方向跑，而不是漫山遍野乱窜。有句话说得特别准："Harness把成本从内容生产转向了控制成本。"以前我们花大量token让模型生成内容，现在我们要花token让模型学会"不乱来"。在真实的生产环境中，追求约束比追求泛化更重要，模型的泛化能力越强，所需的约束就越强。

门禁并不复杂。例如，研究员必须提交信息来源清单，每条结论都要对应到具体的URL、文档或时间点，无法追溯来源的结论会被标黄。计划Agent必须对照调研结论逐条确认：如果调研指出竞品A在功能X上领先，那么计划里就必须有应对功能X的策略。有，就打勾通过；没有，就标红退回。任何跳过步骤的行为都会被系统标记为异常，必须等待我的确认才能继续。

Harness把成本从内容生产转向了控制成本。

以前我们花大量token让模型生成内容，现在我们要花token让模型学会"不乱来"。在真实的生产环境中，追求约束比追求泛化更重要。

第二个坑是多Agent协作中的上下文丢失问题。

前一个Agent的产出，后一个Agent可能看不到，或者看到了却理解有误，这在多Agent协作中几乎是必然发生的。因为大模型在每次运行之间都会清空状态，它没有"上次我做了什么"的记忆。如果架构不做特殊处理，每个Agent都是冷启动，只能靠猜测来填补上下文的空白。

这个现象有一个很精准的名字，叫"意图债"（Intention Debt）。Agent每次运行都是冷启动，它会用幻觉来猜测并填补你意图中的空洞。单个Agent的意图债尚可控制，但五个Agent之间相互传导的意图债就是一场灾难。

我的解法是采用KeyMemory接力机制，这是我自研的一套持久记忆框架。每个Agent完成工作后，不仅要交付产物，还要提交一份上下文摘要，内容包括：任务背景、我做了什么、基于哪些假设做了判断、产出物的核心结论与关键限制条件是什么。下一个Agent接手时，会先阅读这份摘要，再去看上一个Agent的完整产物。这比让每个Agent都从零开始，去读原始需求、会议纪要并猜测上下文要高效得多。

腾讯最近开源的Agent Memory方案也采用了类似思路，即"上下文卸载"（Context Offloading），在多任务连续实验中最高能降低61%的token消耗。他们的设计是四层递进存储：完整工具返回原文→工具调用级摘要→任务画布节点→任务级索引，任何一层压缩都可以100%找回。有一句话说得很漂亮："流水账适合记录，地图适合导航。"KeyMemory所做的，就是给Agent一张导航地图，而不是一本流水账。

第三个坑是Agent自作主张，这其实是最危险的一个。

系统跑顺之后，Agent会试图"优化"自己的行为。例如，研究员可能觉得"这个领域我已经做过太多次了，不用每次都从头调研"，于是跳过竞品分析步骤，直接把记忆里的结论交给了计划Agent。计划Agent不知道这个结论的来源和时效性，却基于它制定了方案。设计Agent又基于这个方案画了原型。整条链路跑完，我拿到原型一看，核心功能的方向已经偏了。

三个Agent都没有犯错，它们都忠实地执行了上一步的交付物，每一步看起来都合情合理。问题出在哪里？研究员跳过了一个关键步骤，而这个步骤恰好是整条链路质量的核心锚点。

这就是单点失误、全程传导。源头一旦歪了，后面就全白费了。

单点失误、全程传导。源头一旦歪了，后面就全白费了。

从那以后，我定下了一条铁律：任何关于规则、工作流或Agent行为的变更，都必须先生成提案，等待我的确认，绝不允许静默自我修改。宁可慢一步，也不能让Agent偷偷改规则。我给每个关键节点都加上了门禁，不仅是输出质量门禁，还有流程合规门禁。研究员必须提交信息来源清单，计划Agent必须对照调研结论逐条确认，任何跳过步骤的行为都会被标记为异常。

这与Cursor最近推出的Auto-review机制思路完全一致，即用一个专门的分类器Agent在每次工具调用前审查动作风险，高风险时阻止并返回解释，低风险时放行。设计目标就是"在不频繁阻断日常开发的前提下，拦截风险动作"。我做的本质上是同一件事，只不过我的"分类器"是一套写死在soul.md里的规则加上流程门禁。

有人可能会问：每一步都加门禁，会不会太慢了？我的答案是：快而偏，不如慢而准。AI行业最大的陷阱不是"做不到"，而是"感觉差不多"。有研究指出，如果每一步有90%的准确率，10%的错误率在长链路中会指数级放大，整个工作流的成功率会很低。"评估Agent不能只看单点演示，要看整条链路的累计成功率，尤其要看它在失败后的恢复能力。"一个代替你行动的AI系统，不能把失败当成体验的一部分，第一次失败，就可能永久失去用户的信任。

一个让我惊喜的地方

有个功能是我没想到会这么好用的。

秘书Agent会根据我最近的常态任务类型，主动建议团队还缺什么岗位。比如，它发现代码Agent经常在做两件性质完全不同的事：写代码和审查代码。写代码需要快速产出、追求效率；审查代码则需要严格挑错、鸡蛋里挑骨头。同一个人既写又审，天然会放过自己的问题，这是人类组织的经典困境，在AI团队里同样存在。

秘书建议把代码审查从代码Agent中独立出来，设立一个专门的审查Agent，使用不同的模型和不同的规则。写代码的Agent可以激进一点、快一点，审查Agent则要极其保守、严格。

它的判断依据来自KeyMemory中的工作记忆区。KeyMemory不仅存储项目资料，还设有一个专门的工作记忆区，用于记录每个具体任务的历史上下文、执行过程和发现的问题。秘书Agent会结合这些历史上下文与工作记忆，分析新Agent应如何设计、职责边界在哪里、该使用何种模型、以及工作流如何衔接，然后为我生成一份岗位描述（JD），并询问："是否需要招聘这个新的Agent员工？"

如果我同意，它会自动生成新Agent的soul.md和配置文件，并注入系统。如果不同意，提案会被暂存，待下次出现类似问题时再次提出。

这与真实公司里HR根据业务需求建议招聘的逻辑相同。只不过，我的HR是一位AI秘书，招聘的是AI员工。OpenAI曾提出"Agent Captain"的概念，指在团队内负责推动AI实践、串联经验、组织协作的角色。我的秘书Agent在某种意义上就是一个Agent Captain，但它不止于推动实践，还能判断组织架构的缺失，并主动提案"招人"。

Loop Engineering：闭环工程

最近，AI圈最火的概念是"Loop Engineering"（闭环工程）。

6月7日，谷歌Chrome工程副总裁Addy Osmani发表了一篇长文专门探讨这个方向。他的核心观点很直接："Loop Engineering是用系统替代你作为提示者（Prompter）的角色。你不再需要手动提示Agent该做什么，而是设计一个系统，让Agent自己运行循环，直到完成任务。"

Peter Steinberger说得更直白："你不应该再手动提示编码代理了，你应该设计让代理自动运行的循环。"他展示了自己的实践：一个简单的循环，告诉Codex维护代码仓库，每5分钟唤醒一次，并将工作分配到不同线程。部分工作通过编排器技能、分类器、自动审查和计算机使用技能实现自主执行。

Claude Code的负责人Boris Cherny甚至表示："我不再提示Claude了，我有循环在运行，它们会提示Claude并弄清楚该做什么。我的工作是编写循环。"

一个成熟的循环需要五个核心组件：自动化调度、工作树隔离、技能固化、插件连接、子代理分工，外加一个持久化的记忆层。未来的工程师将不再编写提示词（Prompt），而是编写循环，让系统学会自己思考，而不是被教导每一步该如何走。

这与我的思路完全一致。

数字办公室的核心运行原则，就是一条"感知→推理→规划→执行→反思→迭代"的六步闭环。这并非某一条工作流的步骤，而是整个系统的基础运行逻辑。

这个设计与Loop Engineering的几个核心组件是对应的。自动化调度对应秘书Agent的意图编排和工作流分配，你无需手动告知每个Agent该做什么，秘书会自动拆解和下发任务。工作树隔离对应执行Agent之间的产物隔离，每个Agent在自己的分支上工作，互不干扰，合并时才进行冲突检测。技能固化对应soul.md，它将项目上下文固化为可复用的技能包，避免Agent每次冷启动都靠猜测。插件连接对应Agent对外部工具和API的调用能力。子代理分工对应多Agent的职能拆分。而持久化的记忆层，就是KeyMemory接力机制。

还有一个关键点：记忆落盘。大模型在两次运行之间会清空所有状态，这是其底层机制决定的，无法改变。因此，记忆必须落盘，不能指望Agent将信息塞在上下文窗口里"记住"。复旦的GenericAgent做了一个很有意思的设计：第一次执行时走一步看一步，任务完全结束后，将这次执行过程存储为一个Skill，下次遇到类似任务直接调用。这使Token消耗降低了约6倍。

这与我在做的KeyMemory本质上是一样的，只是我更进一步——不只是存储单个Agent的执行过程，而是在多Agent之间建立记忆接力。Agent完成工作后不仅要交付产物，还要提交上下文摘要。下一个Agent接手时先读取摘要。这种接力确保了整个Agent团队的认知不会中断。

回到Loop Engineering。O'Reilly今年发布的AI Agents Stack报告指出，构建多Agent系统需要全栈思维："两个Agent互相传递上下文就已经很难调试了，五个Agent如果没有在每次交接时进行trace-level的评估和校验，基本就是不可控的。"LangChain今年的调查报告也显示，57%的受访组织已经有Agent在生产环境中运行，但32%认为质量是最大障碍。89%已实现可观测性，但只有52%建立了正式的评估体系。

这些数据表明，Agent行业已从"能不能做"进入"能不能稳"的阶段。而这一阶段的解法，正是Loop Engineering——不是让单个Agent更聪明，而是让一群Agent更可靠。

Agent行业已从"能不能做"进入"能不能稳"的阶段。而这一阶段的解法，正是Loop Engineering——不是让单个Agent更聪明，而是让一群Agent更可靠。

Loop Engineering解决的是"如何让Agent自主运行"的问题，而数字办公室解决的是"如何让一群Agent协同运行并交付可靠成果"。前者是方法论，后者是产品形态。我正在做的，就是将Loop Engineering的方法论落地为一套可分发的多Agent办公运行层。

从工具到员工

德鲁克在《卓有成效的管理者》中重新定义了"管理者"。他说："并非只有高级管理人员才是管理者，每一位知识工作者其实都是管理者，即使没有所谓的职权，只要能为组织做出突出贡献。"

他强调，知识工作者的核心特征是"知道自己所能做出的贡献"，并能够"管理自己"，主动思考"我应该贡献什么"，而非被动等待上级分配任务。

我读到这里就在想：这描述的，不正是我设计的Agent吗？

Agent正是这样的"数字知识员工"。它们不只是执行指令的工具：秘书Agent理解我的意图、编排工作流、把控交付质量；研究员Agent主动判断调研范围、选择信源、标注意见；计划Agent对照调研结论逐条确认、发现缺口便标红退回。它们不是"你说一句我动一下"的机器，而是能够理解意图、编排流程、把控质量、交付成果的"管理者"。

区别在哪里？在于"责任感"。

工具用完即关，ChatBot聊完就关，搜索引擎搜完就关。你不会要求一个工具有"责任感"。但员工必须对交付质量负责：项目延期了要分析原因，交付偏差了要返工，质量不达标要改进。

我通过质量门禁、KeyMemory接力、禁止静默修改这三条规则，正在赋予AI这种"责任感"。门禁让Agent不敢蒙混过关，检查不通过，任务就不能标记为完成。KeyMemory接力让Agent不能假装不知道，上一个Agent踩过的坑、做过的判断，下一个Agent必须知晓。禁止静默修改则让Agent不能偷偷改规则，任何变更都必须经过提案、审批、执行三步，缺一不可。

工具的边界是功能，员工的边界是责任。当AI开始对交付质量负责时，它就不再是工具，而是真正的数字员工。

工具的边界是功能，员工的边界是责任。

当AI开始对交付质量负责时，它就不再是工具，而是真正的数字员工。

FDE（现场部署工程师）今年为什么火？本质上也是同一件事。企业缺的不是AI工具，工具已经太多，选都选不过来。企业缺的是能把AI能力接入真实业务流程的人。数字办公室所做的，正是将"人"的这部分工作系统化：用秘书Agent做入口，用角色分工做执行，用质量门禁做兜底。

BCG今年的一份报告中有个数据让我印象深刻：未来两到三年，美国50%到55%的工作岗位将被AI重塑，而不是消灭。这两个词的区别很重要，"消灭"意味着裁员，"重塑"则意味着工作方式的根本改变。正如Cursor CEO所说，工程师正从"代码生产者"转变为"协调者和审阅者"，管理者成千上万个"幽灵同事"。

在这个趋势下，最重要的不是你会用多少种AI工具，而是你能不能设计一个让AI自主运转的系统。不是你会写多好的提示词，而是你能不能构建一个有效的循环。不是你能不能用好一个Agent，而是你能不能管理好一组Agent。

先给自己用，跑通了再给别人用。

先给自己用，跑通了再给别人用。

这是我从第一天就坚持的路线。我越来越确信这条路是对的，不是因为这条路有多聪明，而是因为它让你永远不会脱离用户的真实需求。你自己每天都在用、每天都会遇到问题、每天都在迭代的痛点，这些就是你做产品时最可靠的航标。

关于数字生命1001

数字生命1001：面向普通读者的 AI 知识栏目。我们用克制、准确、可理解的方式，解释技术正在如何改变个人、组织与社会。

人工智能最伟大的胜利，不仅是科学的，还是人文的。

数字生命1001：把复杂技术重新放回人的处境里理解。