核心内容摘要
小，也能有大世界
这是一个非常经典且触及 AI 架构本质的问题。
在目前的 AI Agent智能体架构中Sub-agent子智能体和Skills技能/工具的界限可以通过“自主性”和“上下文管理”这两个核心维度来清晰区分。
以下是具体的拆解
核心定义的区别你可以用“员工 vs. 工具”的模型来理解Skills (技能/Tools): 是“工具箱里的锤子”定义它是被调用的原子能力通常是确定性的或者是单步的。
特点它本身没有“脑子”推理能力不知道为什么要用自己只负责接受输入产出输出。
例子GoogleSearch()、ReadFile()、Calculator()、RunPythonScript()。
交互模式Agent 觉得需要搜索 - 调用 Search Skill - 获得结果。
Sub-agent (子智能体): 是“外包团队的专员”定义它是一个具有独立推理能力的实体负责处理一个完整的子任务。
它拥有自己的 System Prompt人设和独立的执行循环Loop。
特点它有“脑子”懂得规划。
它可以在内部进行多次尝试、自我纠错直到完成目标后再向主 Agent 汇报。
例子CodeReviewerAgent专门负责查错的、SQLOptimizerAgent专门优化查询的。
交互模式主 Agent 把“优化这段代码”的任务丢给 Sub-agent - Sub-agent 自己思考、调用 Skills、测试、修改 - 最终只返回优化好的代码给主 Agent。
关键差异点上下文压缩与隔离在架构设计中Sub-agent 存在的一个核心意义就在于上下文Context的压缩与隔离维度Skills (技能)Sub-agent (子智能体)上下文 (Context)无状态或并在主线程。
使用 Skill 的过程、参数和返回结果通常直接暴露在主 Agent 的对话历史里。
独立隔离。
Sub-agent 有自己的对话历史。
它在内部思考了10轮最后只把结论返回给主 Agent。
主 Agent 的 Context 不会被中间过程污染。
自主性 (Agency)被动。
必须由 Agent 明确调用。
主动/半主动。
一旦接受任务它自己决定怎么做甚至可以调用它自己的 Skills。
容错率低。
工具报错通常直接抛出异常需要主 Agent 来处理。
高。
Sub-agent 可以在内部看到报错自己尝试修复修好了再汇报。
复杂度原子级操作(Atomic)。
任务级流程(Workflow)。
场景举例代码重构假设要开发一个“代码重构功能”如果用 Skills 模式主 Agent 的思维链是“我先读取文件 ASkill 1分析后发现需要改名我调用重命名工具Skill 2然后我再运行测试Skill 3…”后果主 Agent 的上下文里塞满了文件内容、中间步骤、测试日志Token 消耗巨大且容易迷失Lost in the middle。
如果用 Sub-agent 模式主 Agent 的指令是“RefactorAgent帮我重构下这个模块。
”RefactorAgent (Sub-agent)接手。
它自己在“小黑屋”里读文件、改代码、跑测试、报错、再改、再跑…这些繁琐的过程主 Agent 都不用管。
最后RefactorAgent完成工作只回复“搞定了这是最终的 Diff。
”优势Context 被极致压缩。
主 Agent 只看到了“请求”和“结果”中间的“思考过程”被封装在了 Sub-agent 内部。
总结如果你只是想执行一个动作查天气、发邮件、读文件应该定义为Skill。
如果你是想委托一个职责写测试用例、做代码审查、处理复杂的客户投诉并且希望它能自我管理过程、不占用主线程的上下文空间应该定义为Sub-agent。