一个代理，多个专家：为何个人AI应负责任务分配而非包揽所有工作。
个人AI助手作为协调者能发挥更好作用：它将任务分配给编码工具、模型以及普通脚本，并为它们设置不同级别的权限。
来源: I Stopped Trying to Build One AI Agent That Does Everything
Qwen、Nemotron、Gemma、DeepSeek。本地推理、AWS Bedrock、Azure。不同的运行环境、不同的规模、不同的价格，以及不同程度的失望。针对Hermes、Codex、OpenCode、本地模型以及云API进行的一系列实验，往往始于一种信念：存在一个正确的模型有待被发现。但迟早会发现这是个错误的问题。其背后还隐藏着另一个假设，而且这个假设更为有趣：为何个人智能体必须亲自处理所有事情？
贾维斯的梦想
第一种架构简单到近乎可笑：一个人，然后是一个智能体，再然后就是一切。
发给该智能代理的任务内容可能包括：查看项目进度、修复某个代码库中的问题、列出明天的日程、报告Linux服务器的运行状态、研究某个主题并提炼关键内容。该智能代理需处理所有这些任务。
这听起来很棒，但问题也正从这里开始出现，因为所有任务都涉及庞大的API接口。
某些任务已有更好的工具可用
编程就是最典型的例子。Codex和OpenCode并非仅仅是与模型相连的聊天窗口，它们是在编程环境中运行的工具。它们能够理解代码库结构、读取和搜索文件、同时编辑多个文件、执行命令、检查错误、运行测试、查看差异并持续迭代。这些都是高度专业化的功能。
现在假设让这个个人智能代理去实现项目中的某个功能，有两种可行的方法。
方法一。为该智能体提供功能极为强大的模型、文件系统访问权限以及shell访问权限。教会它进行代码仓库操作，同时构建上下文管理、差异处理、命令执行、测试循环以及错误恢复功能。持续优化其编码工作流程。恭喜：一个全新的编码智能体正在被打造中。
方法二。该智能体识别出编码任务后，将其交由Codex或OpenCode处理。显然这种方式更为合理。
助手无需样样精通
这需要一种思维上的转变。个人助手不必是世界上最优秀的程序员、研究员、DevOps工程师、调度员或知识系统专家。它只需要知道该由谁来完成工作。这是一种不同的责任，或许更为重要。
人类组织的工作方式也是如此。首席执行官不会亲自编写每一个后端功能，配置每一个Kubernetes集群，研究每一个市场，制作每一个电子表格，安排每一次会议或回复每一条支持请求。他们的价值在于能够明确需要完成什么任务、由谁来处理以及结果是否可接受。个人AI协调器可以被视为类似的存在——它不会执行所有任务，但足以理解意图从而正确分配工作。
不同形态的系统
用类似以下的结构来取代“人、智能体、一个大型模型以及各类组件”的传统链条：
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
智能助手的任务就此变得清晰明了：它了解用户需求，知晓可用的功能，挑选最合适的方案，提供必要的背景信息，监控处理结果并反馈给用户。这才是真正值得拥有的助手。
聊天作为统一入口
在这种设计中，像 Google Chat 这样的聊天应用才具有实际意义。它不应暴露背后的复杂性。对用户而言，只存在一次对话。比如用户发送“查看今天 X 项目是否有重要进展”的消息，智能助手就需要查询任务系统、查看 GitHub、检查服务器状态、阅读相关资料，或许还会让其他模型进行分析，最后再给出总结。用户无需了解这些过程，也不需要打开多个应用。界面体现的是用户意图，而其背后的所有操作都属于实现细节。
编码作为模型案例
想象一下远离电脑的场景。有一条手机消息称X项目的身份验证流程出现了问题，询问如果问题简单的话能否直接修复。原则上，整个流程是这样的：代理首先确定对应的项目，收集足够的信息以找到代码仓库，判断需要修改代码后，再将任务交给编码代理。Codex或OpenCode会打开代码仓库，进行核查，编辑相关文件，运行测试，检查差异后返回结果。协调器收到结果后会汇报类似以下内容：刷新令牌的验证使用了错误的过期条件，编码代理已修复该问题，相关测试均已通过，以下是具体的修改内容。
在整个过程中是哪个模型生成了哪个令牌其实并不重要，重要的是任务能够正确完成。
模型转化为基础设施
一旦代理成为编排层，是否使用Qwen、DeepSeek、本地模型、Bedrock或Azure之类的问题就不再相互排斥。答案很简单：可以都用，针对不同的任务选择不同的智能模型。小型本地模型负责简单的路由处理，廉价的云模型负责撰写摘要，更强大的推理模型则负责做出关键决策，编程代理则负责管理代码仓库，还有其他专用代理负责其他类型的工作负载。模型变成了基础设施，而基础设施应当是可替换的。
避免依赖单一供应商
模型更新的速度快得惊人。今天看来堪称最佳的选择，六个月后可能就显得平庸不堪。价格变动、服务提供商更替、开源模型不断改进、上下文窗口规模扩大、工具调用功能愈发完善，同时还有新的推理架构出现。如果整个个人设置都依赖模型X来完成所有任务，那么更换模型就会带来不便。更好的做法是：
Task
↓
Router
↓
Best available capability
今天最后一步可能需要某个提供商的服务，明天则可能需要另一个，而工作流不应为此困扰。
路由器可能比模型更重要
人们花费大量时间比较各种模型：A的得分是74，B是78，C能处理百万个上下文标记，D的成本则低60%。这些信息确实有用。但现在想象这样一个系统：它知道A最适合处理某些与编程相关的推理任务，B在分类任务中既快速又便宜，C因为请求可在本地解决而无需使用，还有某个请求根本不需要大语言模型，只需一次API调用即可，有一个请求应直接发送到Codex，还有一个请求则需要在采取任何行动之前先向用户提问。
在这里，部分智能体现在决定如何运用智能的系统中，这比单纯的排行榜有趣得多。
并非每个步骤都需要大语言模型
客服让这件事很容易被遗忘。当被问及服务器是否在线时，客服无需借助拥有2000亿个参数的推理模型来判断服务器是否存在，只需执行健康检查、解读结果并给出答复即可。当被问及剩余磁盘空间多少时，它会执行如下操作：
df -h
然后解析输出结果并给出回复。在每一步都使用成本高昂的推理模型并不等同于具备智能，有时这只是糟糕的工程设计罢了。
权限
一旦智能体能够委托执行操作，就会出现一个更棘手的问题：它到底能做什么？读取日历与发送邮件不同，读取代码仓库与合并拉取请求不同，检查服务器与删除文件也有显著差异。因此，一个实用的个人智能体需要与其工具配套的权限模型，大致如下：
- 读取操作无需请求即可执行。
- 准备草稿和计划也无需请求即可进行。
- 低风险操作可以自动执行。
- 任何可能产生重大影响的操作都需等待人类确认。
当被要求查明服务为何中断时，客服人员可以直接着手处理。如果其判断数据库已损坏并打算删除后重新创建，应先获得确认。自主权不应是非黑即白的，而应根据风险程度进行分级。
记忆与上下文
反对将所有专业工具都变成个人助手的另一个原因是上下文问题。Codex应当了解代码库，但不必知晓用户的全部生活。基础设施工具应熟悉服务器，但不需要记住所有曾经的对话。日历负责记录会议，任务管理器则负责管理任务。协调器则可以成为理解这些系统之间关联的层。
以某个特定项目当前的状况为例。没有单一的数据库查询能够回答这个问题。一个好的答复需要结合近期的开发工作、GitHub上的活动、各项任务、先前的决策、部署状态以及用户接下来的计划。正是这种跨系统的背景信息，使得个人编排层展现出真正的价值。
过度设计的陷阱
其危险性显而易见。按照这种思维方式，很容易画出如下这样的图表：
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
然后花三个月时间建立一个人工智能系统，只为了能询问今天有哪些日程安排。这根本帮不到任何人。整个实验带来的教训是：复杂性必须有其存在的价值。仅仅因为架构图看起来很酷就使用十二个智能体，这是糟糕的理由；而那些能反复节省时间的功能才是合理的依据。
先授权再自主
完全自主的智能体受到了很多关注：给它一个目标，让它运行数小时，让这些智能体之间互相交流并自行做出决策，等一切完成后再回来查看结果。这固然有趣，但并非构建个人系统的合适起点。高度可靠的授权机制应当先于最大程度的自主性。目标应该是指定“执行X任务”，让系统可靠地选择合适的工具或智能体，并汇报执行结果。一旦这一点运作得极为顺畅，自主性就可以逐步提升。
更多专业工具，而非更少
起初的目标似乎是整合：人工智能工具太多，因此要打造一个能取代它们的通用人工智能。但事实证明这是错误的。最终状态很可能是拥有更多专业化的人工智能系统，不同之处在于它们不再需要单独管理，而这正是协调层要解决的。未来或许不再是靠一个人工智能来掌控一切，而是通过一个接口来协调所有系统。两者的差异虽细微，却影响深远。
智能体的作用
在运行了这样的系统、调试各种问题、搭建聊天界面、测试不同模型并深入思考专用编程智能体之后，个人智能体的作用便愈发凸显。它不必是整个系统中最聪明的AI，但必须了解该用户及其使用的系统。它应当能够理解用户的请求、判断哪些背景信息重要、选择合适的功能、知晓自己能做什么、何时需要确认以及如何将结果反馈给用户。做到这些就足够了，其余工作都可以委托给其他智能体处理。
值得拥有的架构
其最终形态大致如下：
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
单个组件并非关键所在。在协调器之下的所有元素都应具备可替换性。出现更优的编码工具？直接替换即可。出现更好的本地模型？同样替换即可。云端推理成本降低？将更多任务转至云端处理。某个服务提供商变得不可靠？绕过它即可。每当人工智能行业发生变化时都重新设计助手的使用方式，这是绝不应该出现的。
个人化人工智能，或许可以逆向发展
大多数人工智能产品都在比拼模型的智能程度，这其实是可以理解的。然而，随着模型不断改进，另一个因素的重要性日益凸显：协同性。这意味着要明白用户的真实意图、所处的上下文、哪些系统至关重要、有哪些可用工具、哪种模型最为合适、哪些操作是安全的、何时该寻求帮助，以及何时根本不需要使用人工智能。真正值得拥有的助手未必是那些拥有最高测试分数的，而是能让所有智能技术与软件仿佛融为一个整体系统的助手。
结论简述
一切的起点都是对个人 AI 助手的渴望。实际部署后发现，要拥有一个持续工作的助手本质上是一个基础设施问题。寻找完美的模型则表明，模型选择实际上是一个路由问题。而决定助手应执行何种任务则说明，个人助手从根本上可能是一个协调问题。其架构从追求最聪明的模型并为其配备所有工具，转变为能够理解意图并将任务分配到合适位置的系统。这样的描述虽然远没有贾维斯那么神奇，但却更接近于真正可以构建并日常使用的产物。
相关阅读
- 在LangGraph中构建规划智能体：规划、执行、重新规划、报告 —— 一种用于金融研究的四节点LangGraph规划智能体：结构化规划、支持命名空间识别的工具注册表、重新规划限制以及可追踪的示例运行过程。
- MiniCPM5-2B与4B级模型对比：为何在智能体框架下的表现截然不同 —— 这款25亿参数的模型在单次任务得分上能超越40亿参数的竞争模型，但在智能体框架下的表现则落后两到三倍。问题出在指标版本混淆、本地处理效率以及适用场景上。