一、同一个问题，两个相反的答案

构建智能体（Agent）应用时，开发者迟早会被同一个问题追问：智能体此刻在做什么？它为什么选择这条执行路径而不是另一条？这本质上是对系统可解释性与可控性的诉求。围绕这个问题，业界演化出了两条方向相反的工程路线：一条压低系统默认承担的责任，把复杂度留给使用者按需添加；另一条则把复杂系统拆解为可组合、可卸载的模块，希望运行时也能参与能力配置。

值得注意的是，两者争论的并非功能清单的长短，而是一个更根本的问题：复杂度应该在什么时候进入系统，又该由谁决定它是否存在？理解这场分歧，比记住任何一方的功能列表都更有价值，因为它直接决定了你自己的智能体系统会朝哪个方向生长。

二、路线一：最小内核，让复杂度先证明自己有必要存在

2.1 默认能力刻意保持克制

这条路线的典型做法是：内核默认只向模型暴露极少量原语级工具，例如文件读取、文件写入、内容编辑与命令行执行。至于规划模式、子代理、权限确认弹窗、内置待办清单、后台任务执行、标准化外部工具协议接入等“听起来很有用”的能力，一律不进入默认范围，而是通过类型安全的扩展机制、技能包、提示词模板与第三方包，由使用者按需引入。其设计自述往往相当直白：核心保持克制，工作流由使用者塑造。

这种设计看似只是功能精简，背后其实是一套完整的复杂度观。

2.2 内置能力的三类成本

任何一项进入默认范围的内置能力，都会产生至少三类成本：

1. 上下文成本：模型必须理解更多的工具定义、状态与规则。上下文窗口是稀缺资源，每一段工具说明都在稀释模型对任务本身的注意力；基座越重，长任务中“偏离目标”的概率就越高。
2. 决策成本：智能体每多一个可选行动路径，就多一种误用方式。工具数量与误判概率并非线性关系——当可选动作空间膨胀，模型在错误时机调用错误工具的组合数会快速上升。
3. 维护成本：框架维护者需要处理版本兼容、权限边界与异常状态；使用者则需要理解并绕开这些边界带来的限制。内置能力越多的系统，升级时的破坏面越大。

2.3 举证责任倒置

基于这套成本观，该路线对新功能采取“举证责任倒置”：一项能力不能因为“可能有用”就进入核心，它必须先证明自己值得让所有用户长期承担上述三类成本。评审一个候选能力时，典型的问题清单包括：

• 它能否用现有原语组合实现？
• 高频用户的使用收益，是否明确覆盖全员承担的成本？
• 它失效时的影响半径有多大？能否被单独回滚？

这也解释了该路线为何强调文件、终端与可观察性：计划可以写进文件，天然获得版本比对与回滚能力；多智能体协作可以通过外部进程组织，生命周期交给操作系统管理；权限隔离可以交给容器或沙箱。它优先使用开发者已经理解的操作系统原语，而不是持续制造智能体专属抽象。少一层框架状态机，往往就少一类难以复现的错误。

2.4 优势与代价

优势十分现实：执行过程容易追踪，故障边界与操作系统边界基本重合，开发者能够直接看到系统究竟做了什么。在个人工具与中小型项目中，这种透明性带来的调试效率，往往超过内置高级功能带来的表达力。

代价同样明确：复杂需求需要开发者自行拼装，使用者必须同时扮演架构师角色；跨项目的工程约定只能靠规范而非框架保证；当团队规模扩大，“每个人自己搭脚手架”几乎必然走向碎片化。

这条路线的核心信念可以概括为一句话：缺失的功能可以稍后补上，失控的复杂度却很难再拿掉。

三、路线二：可组合模块，让复杂度成为可撤销的结构

3.1 前提：拒绝容纳并不会让需求消失

另一条路线接受了不同的前提：复杂能力不会因为核心拒绝容纳就自动消失。长任务的规划、多智能体的调度、后台执行、权限治理，这些需求客观存在；区别只在于它们以什么形态进入系统——是散落在每个使用者各自手写的胶水代码里，还是被框架收编为规范化的能力模块。如果框架不提供规范，复杂度并不会减少，只会从“框架内部”转移到“用户代码的每个角落”，反而失去统一治理的机会。

3.2 模块化拆分与生命周期管理

这条路线的做法是把复杂系统拆成职责单一的能力模块：规划器、子代理调度器、后台任务执行器、权限管理器等。每个模块拥有显式的生命周期——注册、激活、运行、停用、卸载；模块之间的依赖关系被显式声明，而不是隐式散落在调用链中。

其中最关键的约束是可撤销性：模块必须实现停用协议，包括释放持有的状态、清理派生的子进程、注销注册的工具。这条约束把软件工程中“加功能容易、删功能难”的熵增问题，转化为一个可被架构强制的结构属性。

3.3 运行时参与能力配置

更进一步，该路线希望运行时也参与能力配置。换言之，能力装配不只发生在开发期的静态配置里，也可以发生在任务执行过程中：运行时根据任务特征动态加载或卸载模块，完成能力协商与降级。例如检测到长周期任务时挂载规划模块与任务队列，短交互任务则保持精简装配，以降低上下文基线。

3.4 优势与代价

治理收益是明显的：能力变更不需要等待框架发版，配置即可生效；故障可以按模块隔离与降级，而不是全系统崩溃；大型团队可以把复杂度的所有权分配到各模块负责人，形成清晰的工程边界。

代价同样无法回避：抽象层数增加，排查问题时需要穿越更多层才能触达真实行为；模块依赖图需要持续治理，否则运行时装配会演变成不可预测的组合爆炸；默认上下文基线更高，对上下文预算紧张的任务不够友好。

四、六个维度的正面对比

对比维度	最小内核路线	可组合模块路线
默认能力	仅文件读写、编辑与命令执行等原语	规划、子代理、后台任务等以模块预置
复杂度引入时机	使用者显式引入，事前决策	开发期配置与运行时装配相结合
上下文占用	基线低，随扩展线性增长	基线较高，可通过卸载动态回收
故障边界	与操作系统边界重合，易追踪	与模块边界重合，依赖生命周期规范
演进方式	功能事后补齐，靠扩展机制	能力以模块形式持续收编
适用场景	个人工具、原型验证、中小项目	多团队共用、长生命周期的企业系统

五、两种扩展模型的代码示意

以下示意伪代码展示了两种思路在接口设计上的差异：

// 思路一：内核只定义扩展点，能力默认缺席
interface Tool {
  name: String
  description: String
  run(input: Any): Promise<ToolResult>
}
// 内核仅注册最基础的原语
register(readFile)
register(writeFile)
register(editFile)
register(runCommand)
// 复杂能力由使用者显式引入，随时可整体移除
function loadExtension(ext: ToolPackage) {
  validateSchema(ext)          // 结构不合规直接拒绝
  ext.tools.forEach(register)
}

// 思路二：能力以模块形式声明，携带完整生命周期
interface CapabilityModule {
  id: String
  depends: List<String>         // 依赖显式声明
  onActivate(ctx: RuntimeContext)
  onDeactivate(): Promise<Void> // 可撤销性是硬约束
}
module planner {
  id: "planner"
  depends: ["task-queue"]
  onActivate: ctx => ctx.registerTool(planTool)
  onDeactivate: async () => { /* 释放状态、清理子进程 */ }
}

两段代码的差异一目了然：前者把“进入系统”设计成一个需要使用者主动完成的动作；后者把“进入与退出”都设计成框架强制的协议。前者信任使用者的判断，后者信任架构的约束——这正是两种哲学在接口层面的投射。

六、场景化选型：如何做决策

选型不是站队，而是匹配。可以从五个问题入手：

1. 团队规模与技能分布：一人或小团队、成员普遍具备系统级开发经验时，最小内核的透明性收益最大；多团队共用一套基础设施时，可组合模块的治理收益更明显。
2. 任务复杂度分布：以短交互任务为主时，重型装配是纯开销；长周期、跨阶段任务占比高时，规划与后台执行模块的价值会持续放大。
3. 可观测性基础：如果团队已有成熟的日志、追踪与告警体系，操作系统原语路线可以充分借力；如果缺少这类基础设施，框架内置的观测能力反而更省力。
4. 安全与合规边界：涉及多租户、权限隔离与审计留痕的场景，模块化的权限治理与沙箱化执行更易满足合规审查。
5. 上下文预算：上下文窗口紧张的应用，应优先控制工具定义与状态规则的数量，向最小内核倾斜。

实践中更常见的是混合策略：以最小内核为基线，只把少数经过验证、高频复用的复杂能力收编为规范模块，其余一律保持外部扩展形态。判断标准回到那句核心原则——该能力是否值得所有用户长期承担三类成本。

七、工程实践建议

无论选择哪条路线，有几件事值得无条件投入：

其一，把“智能体此刻在做什么、为什么”设计为一等公民。用结构化事件日志记录每次工具调用、每次能力装配与卸载，让决策链路可回放、可审计。这比事后补加观测点廉价得多，也是两条路线共同追求的最终目标。

其二，为复杂度设置显式预算。给工具数量、上下文占用率、模块依赖深度设定阈值并纳入告警。复杂度治理失败的项目，几乎都经历过“每项改动都合理、总体早已失控”的过程。

其三，部署侧与开发侧配套。当智能体从本机走向生产环境，通用的容器平台负责隔离与弹性，对象存储沉淀执行产物，日志服务与监控告警承接可观测性。这些通用云上能力与框架内的复杂度治理互为补充：前者解决“跑在哪、怎么观测”，后者解决“能力从哪来、由谁决定”。

结语

复杂度接近守恒：问题本身的复杂度不会消失，只会转移。两条路线争夺的从来不是功能清单，而是复杂度的落点与治理权——一条让它先在系统外排队，证明自己之后再进入；一条让它以规范模块的身份进入，但必须携带可撤销的退出协议。选型的本质，是诚实地回答一个问题：你的团队现阶段有能力、也有意愿治理哪一种复杂度。答案会随团队规模与任务形态变化，而理解这两种哲学的边界，就是为下一次变化预留了调整空间。