多 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 Service2.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 红利怎么真正落进企业。九、小结把全文的核心结论收拢成五条方便快速回顾任务能不能拆看责任和权限是否独立。拆得越细交接丢的信息越多、协调成本越高只有当责任和权限真正独立时拆分才划算。Personal Agent 与 Agent Service 分工明确。前者站在使用者这边负责理解“我要办什么”后者承载专业能力和交付责任负责“这件事怎么办好”。服务合约是协作的前提。接什么任务、要什么材料、交付到哪一步都要在服务接口里写清楚先定义交付再配置连接。接口与授权必须分开管。接口说明“能做什么”授权决定“谁能用”服务使用权和数据访问权要分开检查能调用服务不等于能看数据。技能、工具、远程服务按需选择。需要做事方法用技能需要实时数据或系统操作用工具需要他人独立维护的专业服务才找远程 Agent Service外援不在多在专。