给待办应用塞进AI代理后，我成了最多余的人

AI代理正在以惊人的速度渗透进我们日常使用的每一个工具。一位开发者把AI代理体系接入了自己的待办应用，结果发现整个系统开始自我运转，而他自己反而变成了旁观者。这段来自YouTube的分享，用黑色幽默的方式揭示了一个正在发生的现实：当AI代理开始互相协作，人类的位置在哪里？

从代码审查开始：两个机器人吵了三天

事情的起点是AI代码审查。开发者为每个Pull Request配备了两个AI机器人进行交叉审查——一个负责批准，另一个负责提出修改意见。听起来是个合理的制衡机制，但现实是：这两个代理已经连续争吵了三天，至今没有达成一致。

这个细节本身就很有意思。AI代理之间的"分歧"并非bug，而是多个独立语言模型在相同任务上产生不同判断的自然结果。当人类团队遇到这种情况，通常会开会讨论、投票表决或者由上级拍板。但当你把决策权交给AI代理时，你需要为"代理之间的分歧"设计一套完整的解决机制。

Pull Request（PR）与代码审查机制是理解这段经历的背景。Pull Request 是 GitHub 等代码托管平台的核心协作功能：开发者完成一段代码后，不直接合并到主干，而是发起一个 PR，请求其他人审查。审查者可以批准、评论或要求修改，通常需要至少一人批准才能合并。传统团队里，这个流程依赖人与人之间的沟通与信任。而当审查双方被替换为两个独立的 AI 代理时，问题就从"判断代码是否正确"变成了"当两个代理判断不一致时谁来拍板"。这也是多代理系统中最先暴露的结构性难题：缺乏权威裁决者，分歧就会无限循环。

向量数据库的意外用途：从找牛奶到情感支持酸奶

接下来登场的是向量数据库。在这个待办应用中，每一个任务都会被转化为一个embedding向量。这个设计带来的直接好处是语义搜索——当你搜索"牛奶"时，系统不仅会找到字面匹配的条目，还会找到"采购乳制品"和"情感支持酸奶"这类语义相近但仍有关联的任务。

这个能力看起来像是锦上添花，但它揭示了一个重要趋势：待办事项管理正在从关键词匹配走向语义理解。传统的todo应用只能根据你输入的精确文字来检索，而接入向量数据库之后，你的整个任务列表变成了一个可以被"理解"的知识库。搜索"和客户相关的待办"不再需要你手动打标签，系统自己就能推断出哪些任务涉及客户。

Embedding 与向量数据库是这里的关键技术。Embedding 是把一段文本（一个词、一句话、一条任务）转换成一串高维数字向量的过程，语义相近的文本在向量空间中的距离也更近。向量数据库则专门用于存储和检索这些向量，支持"最近邻搜索"，即找出与查询向量最相似的若干条目。因此搜索"牛奶"时，系统计算的是语义相似度，而非字符匹配，于是"采购乳制品"和"情感支持酸奶"也会被召回。这种检索方式在推荐、知识库问答、RAG（检索增强生成）等场景中已成为标配，也是待办应用从关键词检索升级为语义理解的技术底座。

代理链失控：一份12步计划如何消耗200万token

真正让事情变复杂的，是开发者给每个环节都加上了专职代理。当你在待办中新增一条"送披萨"的任务时，触发了一连串的代理流水线：

1. 规划代理将任务拆解为一个12步执行计划
2. 审查代理审查这个计划的合理性
3. 审批代理审批审查结果
4. 第四个代理写一份Slack摘要通知——尽管没有人会看

这条流水线的问题不在于每一步不合理，而在于每一步都产生了代理之间的分歧。当规划代理和审查代理意见不一致时，开发者又引入了第五个代理：裁判代理，专门用来裁决分歧。

最终的结果是：送一片披萨的任务消耗了200万token，比披萨本身还贵。这个数字不是夸张，它反映的是代理链在缺乏有效收敛机制时的指数级膨胀。每增加一层代理，不仅增加token成本，还增加延迟和不确定性。

Token 与代理链成本需要稍作说明。Token 是语言模型处理文本的基本单位，约等于半个到一个英文单词，中文通常一字约一到两个 token。每一次代理调用都要把上下文（包括历史对话、任务描述、前序代理输出）作为输入发送给模型，这些输入和输出都按 token 计费。当规划、审查、审批、通知、裁决等多层代理串联，且每层都要读取前几层的完整输出时，token 消耗会随层数叠加甚至放大。200 万 token 送一份披萨，正是这种"上下文重复传输 + 多层调用"的典型后果，也说明缺乏成本监控的代理链很容易失控。

MCP服务器与2026年的荒诞：AI替你管理待办，再替你完成待办

开发者还添加了一个MCP服务器，让Claude可以直接"接走"你的任务并代为执行。至此，整个系统的逻辑闭环完成了：

• 你创建一个待办事项
• AI代理帮你规划、审查、审批、通知
• 最终AI代理直接替你完成任务

你的AI管理着一份"你需要做的事情"的清单，然后它自己把这些事情做完了。

开发者最后抛出的那个问题既是玩笑也是预言："到这一步，你为什么还在这里？"

**MCP（Model Context Protocol，模型上下文协议）**是 Anthropic 在 2024 年底提出并开源的开放协议，目的是让语言模型以统一方式连接外部工具、数据源和服务。简单说，MCP 服务器相当于一个标准化适配层：它把某个应用（如待办、日历、数据库、文件系统）的能力封装成模型可调用的工具，Claude 等模型通过 MCP 客户端即可读取数据或执行操作。这解决了过去每个模型对接每个工具都要单独写适配代码的碎片化问题。正因如此，文中的 Claude 才能"直接接走"待办任务并代为执行，这也是 AI 代理从"建议者"变成"执行者"的关键基础设施。

代理编排的真实困境

这段分享虽然以调侃为主，但它触及了几个真实的技术挑战：

代理间分歧的收敛机制缺失。 多个独立代理对同一任务产生不同判断是常态，但目前的代理框架很少有优雅的分歧解决策略。加一个"裁判代理"看似合理，实际上只是把问题往上推了一层。

成本可见性不足。 200万token送一份披萨的荒诞场景，源于开发者无法直观感知每增加一个代理带来的边际成本。当你的应用跑在API调用之上，每一步代理交互都是真金白银。

人类角色的重新定义。 当AI代理能够自主规划、审查并执行任务时，人类在待办应用中的角色从"执行者"变成了"目标设定者"。这未必是坏事——但前提是你得接受自己只负责"想做什么"，而不是"怎么做"。

这位开发者的经历不是孤例。随着MCP协议和代理编排框架的普及，越来越多的开发者会在自己的应用中遇到类似的问题：代理很好用，但代理之间的协作很难管。而最难管的部分，恰恰是你自己还需要在这些代理之间扮演什么角色。