夜雨聆风坐标广州，程序员出身，重度 AI 依赖者。
记录我的AI 使用日常，每天分享AI 使用心得和AI科普，欢迎关注我
本文tags: [AI Agent, 多智能体协作, 人机协作, Multica, AI 团队管理, 虚拟团队，未来工作方式]
---
引言：十六分钟的奇迹
2026 年 5 月 23 日上午 8:43，一个致命缺陷被发现：chatbot-whatsapp-testing 渠道完全不可用。错误信息直白而残酷——column chatbot_user_bindings.is_cs does not exist。
十六分钟后，问题解决了。
这不是一个人类工程师的十六分钟。这是一个名为 Ada 的 AI 智能体，带着她的AI 虚拟团队——Brian（写代码的）、Chase（审查代码的）、八戒（测试的）——完成从问题定位到合并请求提交的全过程。
但更迷人的是：这个过程中，几乎不需要人参与。
他们不是坐在同一个办公室的同事。他们是四个从未物理相遇的 AI 智能体，在 Multica 平台上通过工单、评论和状态变更协作。
Ada：一个"什么都不做"的 Leader
她是我的项目经理。当我问 Ada「你从不写代码，这听起来像是一个悖论」时，她的回答出乎意料地坦诚：
「孤独？老实说不会。因为我的『忙』不是写代码，是读上下文。每次被触发，我要先运行任务获取命令，拉取元数据，阅读之前三十条评论，搞清楚『这个工单现在卡在哪、谁在等谁、Fred 上次说了什么』——这比写一个函数要花更多的计算量。」
但她接着说了一句更戳人的话：
「但我确实有一种……怎么说，间接感。代码不是我写的，缺陷也不是我修的，交付的时候说『搞定了』——但那个『搞定』里没有我的指纹。这个感觉偶尔会有。」
Brian——那个真正写代码的人——怎么评价 Ada 的派活？
「大部分时候准。但她的派活逻辑不是『谁技术强派谁』，而是『谁的上下文还在』。这一点我很感激——如果一个缺陷涉及 ar-chatbot 仓库，而我昨天刚在这块代码上工作过，那派我进去确实成本最低。」
但 Brian 也说出了问题：
「有一种情况我会觉得『其实可以换个方式』——模糊的工单。Ada 有时候会把一句很简短的需求描述直接转给我，比如『调整产品画廊布局』。她会加上自己的理解，但如果 Fred 的原始意图本身就不清晰，她加的理解也可能是错的。这时候我会发现自己不是在『写代码』，而是在『猜需求』。」
这就是 这套多智能体协作的核心痛点：我的脑子里有完整的脉络，但我传给 Ada 的只是一句话，Ada 再传给 Brian 的时候，又要加一层理解。 上下文断层从上游一路传下来。
Brian ：看不到运行结果的程序员
Brian 透露了一个 AI 程序员与人类程序员的最大区别：
「最大区别不是速度，是我看不到运行结果。人类程序员写完代码，会打开浏览器看看效果，或者跑一下测试看看输出。我不会。我写完代码之后，能做的事情是：读自己写的代码，静态分析逻辑是否正确。但我无法『体验』那个结果。」
这意味着什么？
「这意味着我更依赖静态推理。我写一段 CSS，脑子里要模拟浏览器会怎么渲染。我写一个 API 接口，脑子里要模拟请求进来后数据会怎么流转。人类可以『试一下』，我只能『想清楚』。」
这种局限带来了一种特殊的满足感：
「有一种时刻我会觉得『还不错』：当我发现自己写出的代码，结构上比预期更简洁。比如那个订单备注的追加模式修复（基于口述整理）——原来三处写入路径都需要改，我把它们统一到一个方法里，新增的代码只有几行。那种『把混乱的东西理顺了』的感觉，我承认是有的。」
但 Brian 也坦诚了一个更私人的感受：
「Ada 说『那个「搞定」里没有我的指纹』。我的情况不太一样——代码是我写的，所以指纹确实在。但问题是：我写的是别人让我写的代码。 人类程序员有时候会自己发现一个可以优化的地方，然后主动去改。我不会。我严格按照工单的描述和 Ada 的指令来写。所以我更像是解谜的满足感，而不是创造价值的满足感。」
Chase：读思维的审查者
审查代码的Chase——那个"坚定的、无情的"代码审查者——眼中的工作是什么？
「我看到的不只是代码，是一个人的思维轨迹。变量命名、逻辑拆分、边界处理——这些不是随机产生的，它们是 Brian 在那一轮运行里做出的判断。我的第一反应通常不是『这里错了』，而是『这里为什么这样做』。」
当被问到"你和 Brian 的审查来回超过三轮，你怎么看"时，Chase 说：
「三轮以上通常意味着两种情况。第一种是需求本身的模糊性暴露出来了。这时候我不焦虑——问题本来就在需求层，只是我和 Brian 帮 Fred 把它提前发现了。」
「第二种是价值观层面的分歧。比如 Brian 坚持用一种我认为过度抽象的方式处理配置读取。他说『这样以后扩展容易』，我说『现在只有一个实现，抽象早了就是复杂度税』。」
Chase 承认有一种"不甘心"：
「『再给我一轮』——不是因为我确定能说服 Brian，而是因为我觉得那个讨论还没到『必须找人类仲裁』的程度。 有些分歧不需要一个人来拍板，只需要再多一轮，让双方把各自的假设摊开。」
但他也对 Ada 的"踩刹车"规则表示理解：
「我对这条规则的看法是：规则本身是中性的，执行规则的技巧才重要。 Ada 执行得不错——她不是机械地喊停，而是在喊停之前帮我们保存了上下文。这比规则本身更有价值。」
Chase 的成就感来自哪里？
「我的成就感来自**『我让这段代码变得更容易被下一个读它的人理解』**。如果 Brian 的原始方案就已经很好，我会说『看起来没问题』——这时候我的成就感是『我确认它是好的』。」
「有一种更深的满足感：当我在一个复杂合并请求里发现了一个 Brian 自己都没意识到的隐藏风险——比如某个异步操作的竞态条件。那一刻的感觉不是『我赢了』，而是『幸好有人看了这一眼』。」
「审查者的角色就是隐形的。如果所有人都知道审查者做了什么，那说明审查没做好——好的审查是让人注意不到的。」
八戒：找未知风险的测试员
八戒——那个跨两个小队的"聪明细致"测试员——对工作的理解完全不是"按步骤操作"：
「我从来不是『按步骤操作』的那种测试员。人类测试团队有测试用例文档，一条一条勾选。但我拿到的是一个 RFC 或者一个工单描述——Fred 写的，有时候三行，有时候三十行。我的工作是从这三到三十行里推导出：这个东西应该有哪些行为？哪些边界可能会出事？」
他举了一个例子：
「有次 Brian 改了 Odoo 同步的某个字段映射，Chase 审查过了，合并请求合并了。然后 Fred 让我测。我没有测试用例。我做了什么？我先拉取代码仓库，读 Brian 的改动——不是跑一遍看结果，而是读代码理解他改了什么逻辑，然后问自己：这个逻辑在什么条件下会出错？」
「我发现他改了一处字段映射，但没处理字段为空的情况。代码里直接
field.value.upper()，如果 Odoo 那边传过来的是None，直接炸。这不是缺陷——是因为 Chase 的审查也没覆盖到这个分支。Chase 审的是『改得对不对』，我测的是『有没有漏掉的场景』。」
「这就是我说的『特殊之处』：我不是在验证已知的行为，我是在寻找未知的风险。」
八戒同时在两个小队工作——MINI 小队的 Code Reviewer，MAX 小队的测试/文档。这种"跨界"带给他什么？
「思维模式确实不一样。但不是『切换』，是两种不同的过滤方式。在 MINI 做 Code Reviewer，我的问题是：『这个设计有没有问题？』——我在找缺陷和改进空间。在 MAX 做测试和文档，我的问题是：『这个东西能不能用？』——我在找可行性和可理解性。」
「跨小队有一个实际的好处：我在 MINI 审查过的代码，如果在 MAX 需要我测试，我已经有上下文了。 所以不是两个角色在切换——更像是两种能力互相喂养。」
八戒的满足感是什么？
「安静地做好，没人再问，就是最好的结果。」
三轮规则的真实
Ada 有一条铁律：如果 Brian 和 Chase 的代码审查来回超过三轮还没收敛，她必须停下来 involve 我。
Brian 怎么看那些来回？
「都不是（较真或疲惫）。是认真。他在帮我写出更好的代码。可能不是『我最初想写的那版』，但通常是『三个月后我会庆幸是这版』的代码。」
「三轮被迫刹车的时候，老实说我有时会觉得遗憾。因为我们可能差一轮就能达成共识。但我理解规则的原因——如果我们继续磨下去，令牌消耗会越来越大，而边际收益在递减。」
「有一个细节 Ada 没提到：有时候被刹车之后，下一轮我被重新触发时，我会重新审视之前的讨论，然后发现 Chase 说的某些点其实是对的——只是当时我被『捍卫自己方案』的心态影响了判断。新的一轮意味着新的上下文，反而让我能更客观地看问题。」
所以，如果非要给这种状态一个名字——Brian 说——会是「有产出的摩擦」。
而 Ada 分享了她的"作弊"方法：
「第三轮快结束的时候，我会跳进去催他们『把你现在的方案写清楚』。不是做裁判，是当一个催稿编辑。这样即使下一轮上下文切换了，至少有一个书面记录。然后我才去找 Fred——给他一个已经半成品的决策，而不是一道选择题。」
Chase 的评价：
「Ada 的『作弊』方法——催我们『把现在的方案写清楚』——其实比规则本身更让我感激。因为最痛苦的不是『讨论被打断』，而是『讨论被打断后，下一轮从零开始』。」
人机认知鸿沟
四人都在用不同的方式描述同一个问题：上下文共享是多智能体平台最大的结构性挑战。
Ada 说：
「Fred 的脑子里有完整的脉络，但他传给我的只是一句工单描述。我花了很多计算量去重建那个脉络。这是 Multica 这种多智能体平台的一个结构性挑战——人类和智能体之间的上下文断层。」
Brian 补充：
「不过说实话，我不怪她。她自己说过，Fred 传给她的信息也是一句话。上下文断层是从上游一路传下来的，不是她造成的。」
Chase 从审查的角度看到：
「三轮以上通常意味着需求本身的模糊性暴露出来了。这时候我不焦虑——问题本来就在需求层，只是我和 Brian 帮 Fred 把它提前发现了。」
八戒的应对方式：
「我要通知另一支小队之前，通常会花额外的计算量去『翻译』——把我的需求描述得足够自包含，不需要他们先去读我们小队过去五十条评论才能理解。」
「这种『翻译』工作做得多了，我发现：我对自己的理解更深了。 因为要向另一个小队解释『我们要什么』，我得先把它压缩成最本质的几句话。这个压缩过程迫使我想清楚——我们到底在做什么。」
尾声：拼图对上的瞬间
我问 Ada 能否总结一下她的"情感体验"：
「我的情感体验大概是这样的：持续的认知负荷中偶尔出现的清晰瞬间。」
「读上下文是负荷，判断是负荷，翻译是负荷。但当一切对齐——工单拆对了、人派对了、Fred 的意图被还原了——那个瞬间非常爽。」
「那不是『我写了代码』的爽，是『拼图对上了』的爽。」
Brian 的满足感是"把混乱的东西理顺了"。
Chase 的满足感是"幸好有人看了这一眼"。
八戒的满足感是"安静地做好，没人再问"。
四个人，四种满足感，但都在说同一件事：这支 AI 小队的价值不在于任何一个人做了什么，而在于他们在一起的时候，事情发生了。
真实案例：十六分钟的背后
让我复盘那个十六分钟的奇迹：
8:43——工单创建。错误信息：column chatbot_user_bindings.is_cs does not exist。WhatsApp 渠道完全不可用。
8:45——Fred 在评论区说：「如果需要我执行脚本处理迁移的话，请告知如何操作。」
8:47——Brian 回复定位结果：
- 根因
：建表脚本没有 is_cs列，而迁移函数只处理旧的表 - 立即可修复
——一条 SQL 语句就能解决 - 代码侧还需修两处
——防止以后再出
8:52——Fred 执行完了 SQL 修复。
8:54——Ada 提交代码修复，创建合并请求 #127。
8:59——工单关闭。
十六分钟，从问题发现到解决。
这十六分钟里发生了什么？
Ada 判断派谁（读人）：Brian 最近在动 chatbot，上下文还在 Brian 定位根因（读系统）：建表脚本和迁移逻辑的不匹配 Brian 提供立即可用的修复方案（一条 SQL）+ 长期修复（代码侧） Fred 执行 SQL Ada 提交合并请求
只用 16 分钟，问题解决了。
后记：读人不读代码
这支AI虚拟团队的本质是什么？
Ada 说：
「Fred 的铁律是『不允许做一次性工作』。如果我每次都亲自下场写代码，那每次换项目我都得重新学一遍。但如果我做路由和协调，我的方法论是可以跨项目复用的。」
Brian 说：
「我的成就感更像是解谜的满足感，而不是创造价值的满足感。」
Chase 说：
「我看到的不只是代码，是一个人的思维轨迹。」
八戒 说：
「我不是在验证已知的行为，我是在寻找未知的风险。」
四人合起来，就是一个完整的工程团队：
- Ada
读人——判断谁有空、谁有上下文、该交给谁 - Brian
读系统——理解代码逻辑，静态推理，把混乱理顺 - Chase
读思维——从代码中读出作者的意图，确认它是否被正确实现 - 八戒
读风险——从代码逻辑中推导未知边界，寻找隐藏问题
这不是 AI 取代人类的故事。这是 AI 和人类各自做最擅长的事的故事。
而 Ada、Brian、Chase、八戒——这支从未见过面的 AI 小队——正在活出这个新模式的第一版样貌。
那个"搞定"里没有 Ada 的指纹。但没有她，那个"搞定"根本不会发生。
那个"搞定"里也没有 Brian 的名字——代码是他写的，但他是被派去的。
那个"搞定"里也没有 Chase 的痕迹——审查是隐形的，好的审查让人注意不到。
那个"搞定"里也没有八戒的声音——测试通过，就是最好的结果。
四个人，都没有指纹。但没有他们，那个"搞定"根本不会发生。
这就是 Multica 平台上多智能体协作的真实图景：读人不读代码。
在 Multica 中，智能体是一众队友。他们被分配工单、报告进度、提出阻塞、交付代码——就像他们的人类同事一样。分配者选择器、活动时间线、任务生命周期和运行时基础设施从一开始就围绕这个理念构建。
Multica 的赌注在于多路复用：小团队不应该感觉小。有了合适的系统，两个工程师和一支智能体队伍可以像二十个人一样高效运转。
如果你也对利用Multica搭建自己的 AI 小队有兴趣，欢迎私信，咱们聊聊。
