多 Agent 协作与任务委派：Personal Agent 如何按服务合约调用 Agent Service

摘要：多 Agent 协作不是拆得越细越好，关键看责任和权限是否独立。本文讲透任务委派：Personal Agent 与 Agent Service 如何按服务合约协作，接口与授权为何必须分离，以及 Agent 防火墙如何守住边界。

本文目录

• 一、先给结论：任务能不能拆，看 "责任和权限是否独立"
• 二、两种角色的分工：Personal Agent 与 Agent Service
• 三、从 "自己的子 Agent" 到 "别人的专业 Agent"
• 四、把专业能力开放出去，先写清服务接口
• 五、接口与授权分开管：能做什么 vs 谁能调用
• 六、任务委派，离不开 Agent 防火墙
• 七、装个技能、接个工具，还是找另一个 Agent？
• 八、一个人，同时服务百万人

一、先给结论：任务能不能拆，看“责任和权限是否独立”

多 Agent 协作最常踩的坑，不是拆得不够，而是拆得太多。

Anthropic 今年初给做智能体的团队提了个醒：别把一个任务拆给一堆 Agent。很多团队把规划、执行、审核拆给不同的 Agent，结果每次交接都丢信息，协调成本比干活还高。拆得越细，丢得越多。

但同一篇文章也承认：需要专业分工的时候，多个 Agent 确实更好用。

所以问题从来不是“要不要多个 AI”，而是——

你的 AI 不需要什么都会，它只需要知道该找谁。

比如一位招聘负责人想筛一批简历。他的 Agent 已经了解岗位要求，但真正专业的简历分析能力，掌握在另一支团队维护的专业 Agent 手里。两者之间，需要一种明确的协作方式。本文要讲的“任务委派”，解决的就是这件事：让 Agent A 向 Agent B 发起服务请求，直接调用 B 已经搭好的专业能力。

二、两种角色的分工：Personal Agent 与 Agent Service

2.1 Personal Agent：站在使用者这边

一个人的 Agent，可以熟悉他的工作目标、表达习惯和手上正在推进的事。

2.2 Agent Service：承载专业能力和交付责任

但别的机构掌握的资料、内部系统的权限、特定业务的处理标准，始终掌握在对应的服务方手里。把这些全部复制进你的个人 Agent，既不现实，也不合适：业务规则会更新，资料有使用范围，系统权限更不能随便交出去。

更合理的分工是：你的 Agent 负责理解“我要办什么”，专业 Agent 负责“这件事怎么办好”。前者叫 Personal Agent，站在使用者这一边；后者叫 Agent Service，承载专业能力和交付责任。任务委派，就是在这两边之间建立起服务调用关系。

2.3 对专业人士的意义

这件事对专业人士意味着一个变化：以后的专业人士，不只被人找，还会被 AI 找。

三、从“自己的子 Agent”到“别人的专业 Agent”

3.1 子 Agent 模式：同一环境内的调度

原有的子 Agent 模式，是主 Agent 在同一个运行环境里，调度创建者自己的几个子 Agent，各干一摊活。

3.2 远程 Agent Service：把能力开放成服务

远程 Agent Service 把协作的范围扩大了：一个独立运行的 Agent，可以把自己的能力作为服务，开放给其他 Agent 调用。

3.3 招聘场景的完整协作链路

还是拿招聘来说：

• Agent A 接住招聘负责人的需求，明确岗位和筛选标准；

• Agent B 由专业服务方维护，提供约定范围内的简历筛选服务；

• A 按 B 的要求提交材料，B 处理完把结果交回，A 接着往下推进。

关键在于，双方只围绕一项明确的工作衔接。A 拿不到 B 的全部资料和内部权限；B 也不用接手 A 手上的所有事。各管一段，各守边界。

对服务提供者来说，这意味着：你搭好的专业 Agent，除了直接接待客户，还能成为别人的 AI 完成任务时随时调用的一项服务。

四、把专业能力开放出去，先写清服务接口

两个 Agent 能互发消息，不等于能做成一笔业务。服务方得先说清楚：接什么任务，要什么材料，交付到哪一步。这些约定，写在服务接口里。

以简历筛选服务为例，可以这样定义：

维度	定义
接什么任务	按岗位要求初筛简历
要什么材料	岗位描述、筛选标准、简历文件
交付什么	每份简历的筛选结论和理由，最终录用判断留给招聘负责人

这些能力和输入要求，合起来就是 Service Contract（服务合约）。接口给专业能力装上了一扇明确的门，调用方也知道该怎么敲门。

同一个 Agent 可能连着好几个系统、会好几种业务，但不必全部对外开放。创建者可以先从一项范围清楚的服务开始。

这对业务团队提出了一个具体要求：“帮我看看这些人”太宽泛，需要哪些材料、按什么标准、结果给谁判断，都要在设计服务时想清楚。先定义交付，再配置连接。

五、接口与授权分开管：能做什么 vs 谁能调用

服务接口说明“能做什么”，授权决定“谁能用”。在任务委派里：

• 调用方配置自己可以连接哪些服务；

• 服务方管理哪些 Agent 可以调用自己。

对于平台之外的调用者，会分配一个专门的服务账号。服务方给这个账号授权后，外部调用者就能在许可范围内使用服务。

开放的程度也要分清：按约定好的接口调用，和允许对方绕开接口、随意下指令，是完全不同的两回事。

如果只需要对方完成一项指定工作，就只围绕这项服务配置权限：

• 允许调用简历筛选服务，不等于能看服务方的全部候选人资料；

• 允许查询订单，也不等于能读所有客户的订单。

能调用这项服务，不等于能看这个人的数据。服务使用权和数据访问权，必须分开检查。

六、任务委派，离不开 Agent 防火墙

6.1 为什么需要独立的安全机制

当一个 Agent 能操作内部系统时，外部请求就不能只靠模型自己判断该不该执行。一个请求可能格式完全合规，却涉及当前调用方无权访问的数据；一次查询也可能顺带返回内部备注、敏感字段。

6.2 三个机制的分工

这就接上了 Agent 防火墙（智能体防火墙）：Agent 提出操作请求，独立的安全机制检查权限，受控的 Operator 执行经过授权的操作。放到任务委派里：

机制	作用
服务合约	划定 B 允许做什么
任务校验	检查 A 这一次的请求合不合规
结果校验	控制哪些信息能交回给 A

所以把 B 接到 A 上，要同时想两件事：A 怎么用好 B 的专业能力，B 怎么守住自己的服务和数据边界。连上了，不代表守住了。

七、装个技能、接个工具，还是找另一个 Agent？

回到开头 Anthropic 的提醒：有了任务委派，也不等于每项工作都要拆成独立的 Agent。先看这项能力到底需要什么：

能力形态	适用场景	由谁维护
技能（Skill）	需要一套做事方法：写作规范、分析步骤、业务判断标准，让当前 Agent 自己用	当前 Agent
工具（Tool）	需要实时数据或确定的系统操作：读一条订单、查库存、提交已授权请求	当前 Agent
远程 Agent Service	需要别人独立维护的专业服务：有自己的业务资料、执行环境和授权要求	服务方

把上面的判断顺序画成流程图，会更直观：从「需要一项新能力」出发，先问是否需要实时数据或确定的系统操作，再问是否需要他人独立维护的专业服务，最终分流到技能、工具、远程 Agent Service 三条路径。

flowchart TD
    A[需要一项新能力] --> B{是否需要实时数据或确定的系统操作?}
    B -- 是 --> C[工具 Tool]
    B -- 否 --> D{是否需要他人独立维护的专业服务?}
    D -- 是 --> E[远程 Agent Service]
    D -- 否 --> F[技能 Skill]
    C --> G[由当前 Agent 维护与调用]
    E --> H[由服务方维护，按合约交付]
    F --> G

三种方式可以组合：A 用技能和工具搞定日常工作，遇到独立的专业任务，再去调用 B。

委不委派，最终看任务完成效果、上下文传递，以及实际成本和等待时间。需要来回共享大量细节的任务，别急着拆；输入和结果清楚、责任和权限独立的服务，最适合交出去。

外援不在多，在专。

八、一个人，同时服务百万人

8.1 服务方要回答的三个问题

对专业服务提供者来说，做出一个 Agent 之后，还得回答三个问题：谁会来用它？怎么把任务交给它？它被允许做到哪一步？

任务委派要做的，就是把这三个问题变成具体的产品机制：定义服务接口，配置调用关系，管理身份与授权。

8.2 专业能力走出去

创建者继续维护自己的专业知识、业务方法和执行标准；调用方按约定使用服务。专业能力不用在每个调用方那里重搭一遍，就能进入更多人的工作。

想想这意味着什么：以前，一个专业人士的经验，一次只能服务一个客户。做成 Agent Service，它既能直接接待客户，也能同时被成千上万个 AI 助手调用。

一个人，同时服务百万人。靠的不是群发，而是每一次调用都按合约、在边界内交付。

8.3 收尾：对内一套事实，对外一个入口

在团队内部，workspace 让人和 AI 看到同一份事实；任务委派，则让团队沉淀下来的专业能力走出去，被更多人的 AI 调用。对内一套事实，对外一个入口。

这也是 OpenHex 作为 Agent Service 平台的方向：让个人、团队和企业的专业能力，成为可以被调用、按边界交付的服务。

如果你也在关注 Agent 怎么安全地调用外部专业能力，欢迎一起探讨这波 AI 红利怎么真正落进企业。

九、小结

把全文的核心结论收拢成五条，方便快速回顾：

1. 任务能不能拆，看责任和权限是否独立。拆得越细，交接丢的信息越多、协调成本越高；只有当责任和权限真正独立时，拆分才划算。
2. Personal Agent 与 Agent Service 分工明确。前者站在使用者这边，负责理解“我要办什么”；后者承载专业能力和交付责任，负责“这件事怎么办好”。
3. 服务合约是协作的前提。接什么任务、要什么材料、交付到哪一步，都要在服务接口里写清楚，先定义交付，再配置连接。
4. 接口与授权必须分开管。接口说明“能做什么”，授权决定“谁能用”；服务使用权和数据访问权要分开检查，能调用服务不等于能看数据。
5. 技能、工具、远程服务按需选择。需要做事方法用技能，需要实时数据或系统操作用工具，需要他人独立维护的专业服务才找远程 Agent Service；外援不在多，在专。