agent-">插件化 Agent 架构：统一任务抽象的技术边界

在 Agent 系统的工程实践中，一个反复出现的诱惑是：把“让另一个 Agent 查资料”“把命令放到后台跑”“继续做，直到目标完成”这三类需求，收敛成同一个通用 Task 对象。接口层面看，这确实整齐——都有 id、status、result、cancel，一套 CRUD 走天下。但只要系统开始接入恢复、权限和失败处理，这个抽象就会迅速漏出裂缝。本文讨论的不是“要不要统一”，而是“统一的边界在哪里”，以及插件化与技能包机制为何可能成为 Agent 能力演进的合理路径。

一、三类“任务”在语义上并不等价

表面相似掩盖了本质差异。拆开看，这三类需求对应的生命周期模型完全不同。

委派型任务（Subagent） 的本质是“一次带上下文的推理外包”。父 Agent 把一段对话历史、若干工具权限和一个子目标交给子 Agent，子 Agent 在自己的上下文窗口内完成推理，返回结果。它的关键资产是对话历史：结果的含义依赖于它看到了什么、做过哪些中间决策。取消一个子 Agent，意味着这段推理链被截断，已产生的中间结论是否保留、保留到什么粒度，都需要显式定义。

后台作业（Job） 的本质是“一个可脱离请求生命周期的执行单元”。它不需要理解对话，只需要执行状态：排队、运行、成功、失败、超时。它的关键资产是执行状态与产物，而不是推理上下文。取消一个作业，语义相对干净——终止进程、清理资源、标记状态。它不需要回答“下一轮该说什么”。

目标驱动任务（Goal） 的本质是“一个持续的收敛过程”。它既需要历史（做过什么、失败了什么），又需要状态（当前进度），还需要一个可判定的完成条件。它的关键难点在于“完成”的定义：是目标达成、是预算耗尽、还是判定无法继续？取消它时，保留的是“已完成的阶段性成果”还是“可续跑的检查点”，这是产品语义问题，不是接口问题。

把三者塞进一个对象，等于要求这个对象同时回答：谁拥有对话历史、谁只保存执行状态、谁可以继续下一轮、取消后保留什么、完成到底代表什么。这些问题的答案互相冲突，最终只能靠一堆可空字段和状态机分支来兼容，抽象反而变成了复杂度来源。

二、统一抽象的三个破裂点

1. 恢复语义不一致

后台作业的恢复是“重跑或续跑”，幂等性由执行体保证；委派型任务的恢复是“带着已有历史继续推理”，需要区分“重放历史”与“续接历史”；目标驱动任务的恢复则涉及检查点设计——哪些中间产物可信、哪些需要重新验证。

如果共用一个 resume() 接口，调用方无法表达自己需要哪一种恢复语义，实现方只能猜测。更糟的是，猜测错误往往不会立即报错，而是在数据一致性上埋雷。

2. 权限模型不一致

委派型任务的权限是“父级权限的子集委派”，需要处理权限收敛与回传；后台作业的权限通常是“一次性凭据+资源范围”；目标驱动任务因为持续时间长，需要处理权限过期与续期。

共用对象意味着权限字段要兼容三种生命周期，最终要么字段膨胀，要么在运行时做类型判断。后者是把编译期问题推迟到运行期，是典型的抽象失败信号。

3. 失败处理不一致

后台作业失败，通常重试即可；委派型任务失败，可能需要父 Agent 重新规划；目标驱动任务失败，往往要区分“可恢复失败”与“目标不可达”。三者的重试策略、退避策略、上报对象都不同。

一个 failed 状态无法承载这些差异。你最终会看到 failed_reason、retryable、owner 等字段被不断追加，直到这个对象变成一张宽表。

三、可行的拆分方式：共享协议，分离对象

结论不是“不要统一”，而是“统一在协议层，分离在对象层”。

可以定义一个所有任务都实现的最小契约，只包含真正通用的部分：

interface TaskHandle {
  id: string
  kind: TaskKind          // 区分语义类型
  status: TaskStatus
  cancel(): Promise<void>
  describe(): TaskDescriptor
}

注意这里刻意不包含 result 和 resume。结果形态与恢复语义因 kind 而异，应由各自的专用接口承载：

• DelegatedTask 暴露历史句柄与结果引用；
• BackgroundJob 暴露产物引用与重试策略；
• GoalTask 暴露进度、检查点与完成判定器。

调用方通过 kind 做分发，或通过能力查询（capability query）判断是否支持某操作。这样既保留了统一入口的整齐，又避免了用一个对象承载互相冲突的语义。

一个常见的反模式是让 result 返回 any，然后靠调用方自行断言。这在原型阶段很爽，在接入权限与恢复后必然反噬。

四、插件化与技能包为何是合理的演进路径

回到架构层面。“一切皆插件+技能包”之所以值得认真对待，不是因为它时髦，而是因为它和上面的拆分逻辑同构。

插件机制解决的正是“能力扩展不修改核心”的问题：核心只定义 TaskHandle 契约与调度、权限、恢复的基础设施，具体任务类型作为插件注册，各自实现自己的生命周期语义。技能包则解决“能力封装与复用”的问题：把一组工具调用、提示模板与失败处理策略打包，作为一个可组合单元被不同任务类型引用。

这种结构带来的实际收益有三点。其一，语义隔离：新增任务类型不需要修改核心状态机，降低了回归风险。其二，权限可收敛：技能包可以声明所需权限，插件在注册时做静态校验，比运行期判断更可靠。其三，演进可观测：每类任务的恢复成功率、失败分布可以独立度量，而不是混在一个大指标里。

需要强调的是，这不等于“Agent 自我进化”。插件化提升的是能力组合与扩展的效率，而自我进化涉及的是目标生成、策略搜索与自我评估，二者不在同一层面。把工程扩展性包装成进化叙事，容易让团队对真实的技术债务产生误判。

五、落地时的几个检查项

在真实系统里推进这套拆分，建议先确认以下几点：

1. 是否为每类任务明确定义了“取消后保留什么”。这是最容易被跳过、也最容易在事后引发数据问题的点。
2. 恢复语义是否写进了接口契约而非文档。文档会过期，类型不会。
3. 权限是否在插件注册期做校验。运行期判断权限，等于把安全问题变成概率问题。
4. 完成判定是否可外部注入。目标驱动任务的“完成”应由策略对象决定，而不是硬编码在任务实现里。
5. 是否为每类任务建立了独立的可观测指标。混在一起的指标无法指导优化。

统一抽象的价值在于降低认知成本，但它的成本必须由真实的语义共性来支付。当三类任务的恢复、权限与失败处理开始互相拉扯时，说明共性已经被透支。此时正确的动作不是继续加字段，而是回到协议层做最小统一，在对象层做语义分离——这也是插件化架构能够真正承载 Agent 能力长期演进的前提。