Agent究竟该如何定义？
很多使用大模型编排的工作流方案里，都会用到 subagent。
理由也很朴素：上下文隔离。
一个复杂任务如果全塞进同一个会话里，前面的探索、错误、临时假设、废弃方案都会留在上下文中，越堆越脏。于是大家开始把一部分工作派给 subagent，让它在另一个上下文里完成，再把结果带回来。
这当然有用。
但 subagent 也是一个值得重新讨论的概念。因为它流行之后，很多人开始把 Agent、subagent、会话、任务执行器混在一起说，最后说得好像它们是一回事。
不是。
要讨论 Agent，第一步不是问它能不能调用工具，也不是问它能不能自主规划，而是先把概念拆清楚：
Agent 是模板，会话是实例。
这个区分很重要。
有人喜欢用操作系统调度进程来类比多个 Agent 协作，说 Agent 就像操作系统里的进程，看起来好像很有道理：它们各自运行、互相通信、被调度、被终止。
但这个类比混淆了 Agent 和会话。
会话才更像进程。
同一个 Agent 可以启动很多次，每次启动都会产生一个独立会话。就像同一个程序可以打开很多个窗口，每个窗口背后是一个独立运行实例。你打开三个浏览器窗口，不会说你安装了三个浏览器；你启动三个写作 Agent 会话，也不该说你定义了三个 Agent。
Agent 更像程序。
它定义的是这个会话该怎么运行，应该遵守什么规则，能调用什么工具，能访问什么资源，遇到问题应该按什么流程处理。
会话是活的运行过程，Agent 是生成这个运行过程的定义。
这个混淆，Claude Code 得负一点责任。
它总是把在主会话里新起一个隔离会话叫作创建 subagent。这个叫法很顺手，也很容易传播，但久而久之，大家就把“创建一个 Agent 的会话”理解成了“创建一个 Agent”。于是 Agent 从一个可复用的抽象定义，被降格成了一次性的任务执行窗口。
这不是小问题。
概念一旦错了，架构就会跟着错。
Agent 应该是什么结构？
如果 Agent 是模板，那这个模板至少应该包含几部分：
第一，身份定义。
它是谁？有什么知识背景？它站在哪个角色上理解问题？
一个安全审查 Agent、一个产品需求 Agent、一个写作 Agent，面对同一个输入时不应该看到同一个世界。身份定义不是为了角色扮演，而是为了建立判断框架。
第二，行为规则。
它应该遵守什么规则？工作流是什么？先做什么，后做什么？什么时候要停下来问人？什么时候可以直接执行？什么时候必须验证？
这部分决定了它的工作方式。
第三，可用工具集合。
它能调用什么工具？能不能读文件？能不能写文件？能不能联网？能不能提交代码？能不能操作浏览器？
工具不是装饰品，它决定了 Agent 的行动边界。
第四，权限范围。
它能操作哪些资源？能看哪些目录？能改哪些文件？能不能访问生产环境？能不能推送远程？能不能删除数据？
工具解决“能做什么动作”，权限解决“能对什么东西做动作”。
第五，记忆。
它应该记住什么？哪些经验可以跨会话复用？哪些错误不能再犯？哪些项目知识应该长期保留？
记忆不应该只是聊天记录的延长，而应该是 Agent 定义的一部分。一个 Agent 如果长期服务于某个领域，它理应能积累对这个领域的理解。
第六，执行逻辑。
这点经常被忽略。
很多人一谈 Agent，就只想到系统提示词，好像写一段身份设定、加一段工具说明，就完成了 Agent 定义。
不够。
Agent 本身的程序执行逻辑也应该算作它的组成部分。不同的执行逻辑，可以生成完全不同类型的 Agent。
一个聊天型 Agent，可能就是用户输入、大模型思考、工具调用、返回结果。
一个工作流 Agent，可能会先把任务拆成结构化计划，再由程序调度多个子会话执行。
一个系统操作 Agent，可能只让大模型生成操作意图，后续步骤由确定性程序接管。
一个审查 Agent，可能必须先收集证据，再输出结论，不能凭感觉判断。
这些差异不是系统提示词能完全表达的。提示词能约束行为，但程序逻辑能塑造行为。
所以，一个更完整的 Agent 定义应该是：
Agent 是一套可实例化的智能行为定义，它由身份、规则、工具、权限、记忆和执行逻辑共同组成。每一次运行，都会生成一个会话实例。
这个定义比“能自主完成任务的软件实体”更工程化，也更准确。
身份和规则为什么要分开？
有人会问：身份定义和行为规则不都是系统提示词吗？为什么还要拆成两部分？
是的，在很多实现里，它们最后可能都会被拼进同一段系统提示词。
但我们现在讨论的是 Agent 的抽象概念，不是某个框架的具体实现。
抽象层面上，它们就应该分开。
身份定义回答“它是谁”。
行为规则回答“它怎么做事”。
一个人可以是医生，但不同医院有不同接诊流程；一个人可以是律师，但不同案件有不同工作规范。身份决定视角，规则决定流程。
把它们拆开之后，每个部分都可以单独设计、单独迭代。
你可以保留“安全审查专家”的身份，但修改它的审查流程；也可以保留同一套审查流程，但换成“性能专家”“合规专家”“架构专家”来执行。
更重要的是，拆开之后，Agent 的结构可以继续扩展。
今天加记忆，明天加评价器，后天加预算策略，再以后加协作协议，都不需要重写整个提示词。它不再是一大坨文本，而是一组可以组合、替换、升级的部件。
这才是工程化。
Agent 能包含其他 Agent 吗？
谈到结构，就会碰到另一个问题：
Agent 能不能包含其他 Agent？
上面提到的 subagent，算不算一种包含关系？
算，但还不够。
在程序语言设计里，如果一个结构体只能包含数字、字符、布尔值这些基本类型，它当然能表达一些东西，但表达能力很有限。
一旦结构体可以包含另一个结构体，事情就变了。
复杂系统开始出现。
树、图、文档、数据库记录、UI 组件、业务对象，几乎都靠这种递归组合能力成长起来。
Agent 也一样。
如果一个 Agent 只能调用工具，不能组合其他 Agent，它的表达能力就会被限制在单体任务执行器的层面。
但如果一个 Agent 可以包含其他 Agent，可以启动它们的会话，可以把任务分发给它们，可以收集结果、校验结果、组织下一步，那么它就不再只是一个会聊天的工具壳，而开始具备系统结构。
这时的 Agent 不只是“一个助手”，而是一种可组合的智能模块。
问题在于，很多平台虽然提供了 subagent，却把它做成了一个被特殊限制的次级对象。
它不能完整继承能力，不能自由调用某些工具，不能继续创建子会话，不能拥有和主 Agent 同等的协作地位。
这就很奇怪。
如果 Agent 的能力由它自己的定义决定，也就是由它的工具、权限、规则、执行逻辑决定，那为什么只因为它是“子”的，就天然低人一等？
一个 Agent 能做什么、不能做什么，应该由它的定义决定，不应该由它是不是 subagent 决定。
所有 Agent 都应该平等。
只有分工不同，没有身份高低。
Claude Code 设计出 subagent，又给它套上各种特殊限制，这个头开得并不好。它让很多人误以为多 Agent 系统天然就是“主会话支配子会话”，而不是“多个 Agent 按协议协作”。
前者是聊天工具的延伸。
后者才是 Agent 系统。
Claude Code 没有那么神奇
说到 Claude Code，还可以顺手泼一点冷水。
当它的源码泄露时，很多人说这下大家可以向 Agent 界的天花板学习了，很多 Agent 工具终于有优秀设计可以抄了。
但如果按前面的定义看，Claude Code 并没有多少神奇的地方。
它当然做得很好，尤其是在工程体验、工具调用、权限提示、上下文管理这些方面。但从 Agent 体系的角度看，它本质上仍然更像一个 chat runner。
用户输入，大模型决策，工具执行，结果回传，大模型继续决策，直到输出答案。
这是一条很经典的链路。
问题是，这条链路里，Agent 大多数时候只是代理角色。
它替大模型调用工具，替大模型管理文件，替大模型拿到上下文，替大模型把结果展示给用户。
主角是谁？
还是大模型。
Agent 更像跑腿的。
这就是“agent”这个词最原始的含义：代理人，代办者，替别人行动的人。
但在 AI 时代，Agent 只能停留在代理角色吗？
我觉得不应该。
Agent 不应该只是代理
如果 Agent 只是代理，那么它的职责很简单：大模型说要调用哪个工具，它就调用哪个工具；大模型说任务完成了，它就把结果交给用户。
这适合聊天工具。
但不适合复杂工作流。
复杂工作流里，真正难的不是“调用工具”，而是“维持秩序”。
比如一个研发任务，可能要经历需求澄清、代码搜索、方案设计、实现、测试、修复、复查、提交、推送。
如果这些步骤全靠大模型在一个长上下文里记住，很容易出问题：
它可能漏掉测试。
它可能忘记前面定过的验收标准。
它可能跳过复查。
它可能在执行到一半时被新信息带偏。
这不是大模型笨，而是大模型本来就不擅长做确定性调度。
程序才擅长。
所以，一个成熟的 Agent 不应该只做代理，还应该承担更多职责。
第一，Agent 应该承担编排职责。
它应该能把任务拆成节点，识别依赖关系，决定哪些可以并行，哪些必须串行，哪些失败后要重试，哪些失败后要交给人。
这里不一定都由大模型决定。大模型可以生成计划，但计划一旦结构化，就应该交给程序调度。
第二，Agent 应该承担治理职责。
它应该知道哪些动作需要权限，哪些资源不能碰，哪些命令危险，哪些结果必须验证。
权限治理不能靠大模型临场自觉。
该拦就拦，该问就问，该记录就记录。
第三，Agent 应该承担记忆职责。
它不只是把历史聊天塞回上下文，而是要把可复用经验沉淀成结构化知识。
什么规则长期有效？什么项目约定不能破坏？什么坑已经踩过？什么用户偏好需要保留？
这些都应该成为 Agent 下一次运行的起点。
第四，Agent 应该承担协议职责。
多 Agent 协作不能只靠自然语言互相喊话。自然语言适合表达意图，但不适合承载稳定协议。
一个 Agent 发给另一个 Agent 的任务，应该有目标、输入、边界、验收标准、输出格式、失败状态。
这套协议越清楚，协作越稳定。
第五，Agent 应该承担验收职责。
大模型说完成了，不等于真的完成了。
Agent 应该能根据事先定义的标准去验证结果。能跑测试就跑测试，能检查文件就检查文件，能对照清单就对照清单。
把“完成”从一句主观判断，变成一个可验证状态。
这才是 Agent 从代理走向系统的关键。
更好的 Agent 体系是什么样？
一个好的 Agent 体系，应该允许自由创建 Agent。
不是只能从平台内置的几个角色里挑，也不是写几个 markdown 文件就假装自己有了完整架构，而是能认真定义身份、规则、工具、权限、记忆、执行逻辑。
它也应该允许自由生成会话。
需要上下文隔离时，就创建新会话；需要长期运行时，就恢复旧会话；需要并行时，就启动多个会话；需要审查时，就创建独立审查会话。
它还应该允许 Agent 组合 Agent。
不是只能有一层 subagent，而是能形成多层结构。一个研发总控 Agent 可以包含需求 Agent、架构 Agent、开发 Agent、测试 Agent、审查 Agent；测试 Agent 下面还可以有单元测试 Agent、集成测试 Agent、回归测试 Agent。
只要权限和协议设计清楚，层级不该被人为限制。
当然，这并不是说层级越多越好。
多 Agent 不是为了热闹，而是为了隔离上下文、分离职责、提高确定性。
能一个会话做完的事，就别拆成十个。需要拆的时候，就应该拆得干净。
最好的 Agent 系统，不是让大模型假装自己是一个公司，也不是让几十个角色在上下文里开会。
它应该找到三者之间的平衡点：
大模型负责理解、推理、生成不确定性内容。
程序负责调度、约束、验证确定性流程。
人负责目标、判断、授权和最终责任。
Agent 就站在三者之间。
它既不是大模型的壳，也不是人的替身，更不是工具调用的传声筒。
它应该是一个秩序生成器。
把人的目标翻译成机器可执行的流程，把大模型的能力限制在可靠边界内，把程序的确定性接入真实任务。
所以，Agent 究竟该如何定义？
我的定义是：
Agent 是一套可实例化、可组合、可治理的智能行为系统。它以大模型为认知引擎，以程序为执行骨架，以工具和权限为行动边界，以记忆和协议维持长期秩序。
如果只把 Agent 当代理，它当然只能替大模型跑腿。
但如果把 Agent 当系统，它就能承担编排、治理、记忆、协作和验收。
这一步跨过去，Agent 才真正开始像一个工程概念，而不是一个营销词。