第 5 章（中）：Agent 是什么
一个 Agent 不只是一个 LLM 调用
上一节讲了 Tool 怎么与 LLM 交互——工具调用循环、Schema 匹配、框架封装。
但一个 Agent 不只是"LLM + 工具"。
一个真正的 Agent 是一个复杂角色的封装——它组合了：
Agent = Skill（操作手册）+ Tool（工具）+ Rule（约束）+ Code（代码能力）+ Workflow（流程编排）缺任何一个，Agent 都只是一个"能调工具的聊天机器人"，不是一个"能独立完成任务的角色"。
一个 Agent 的完整构成
每个 Agent 有五个组成部分：
| 组成部分 | 作用 | 没有它会怎样 |
|---|---|---|
| System Prompt | 定义"你是谁、你做什么" | Agent 不知道自己该干什么 |
| Tool | 定义"你能操作什么" | Agent 只能说话，不能做事 |
| Skill | 定义"你怎么做这件事" | Agent 每次都要重新摸索 |
| Rule | 定义"你不能怎么做" | Agent 会犯已知的错误 |
| Model | 定义"用什么脑子" | 用错模型，杀鸡用牛刀或杀牛用鸡刀 |
关键不只是"有这些组件"，而是每个 Agent 的这五个部分是独立的。
Agent A（文案生成）
├── System Prompt: "你是一个短视频文案写手，从老板视角出发..."
├── Tool: 无（纯文本生成）
├── Skill: 商业自媒体规则 / 个人IP规则 / 热点评价规则
├── Rule: 不讲技术名词、结尾留钩子、反常识开场
└── Model: GPT-4o（需要强创造力）
Agent B（口播剪辑）
├── System Prompt: "你是一个视频渲染引擎的操作员..."
├── Tool: CLI 命令行工具（调用视频产品的渲染能力）
├── Skill: 脚本解析规范
├── Rule: 断句自然、字幕无错别字
└── Model: GPT-4o-mini（不需要强创造力，只需要理解结构）两个 Agent 可能解决同一个大任务的不同环节，但它们的"角色定义"完全不同。
真实案例：用 Agent 做自媒体
我用 Qoder 搭了一条自媒体内容生产流水线——6 个 Agent，每个 Agent 解决一个具体问题：
Agent 1: 情报采集 → 代替你刷手机（爬取、下载、转写）
Agent 2: 内容分析 → 逐篇分析线索（提取观点、评分匹配度）
Agent 3: 选题分析 → 从线索中选选题（按方向分类、生成建议）
Agent 4: 文案生成 → 按 Rule 写脚本（60-75 秒短视频脚本）
Agent 5: 口播剪辑 → 调用 CLI 渲染视频（不调 LLM，调产品工具）
Agent 6: 发布 → 多平台分发（格式适配、定时发布）注意每个 Agent 的组合方式不同：
| Agent | Skill | Tool | Rule | 特殊点 |
|---|---|---|---|---|
| 情报采集 | 爬虫规范 | MediaCrawler + yt-dlp + FunASR | 采集范围约束 | 不调 LLM，纯工具链 |
| 内容分析 | 分析方法论 | 文件读写 | IP 画像匹配规则 | LLM 做分析，Rule 做过滤 |
| 选题分析 | 选题模板 | 文件读写 | 60/30/10 配比规则 | 人拍板选哪个 |
| 文案生成 | 三个方向的创作规则 | 无 | 不讲技术、留钩子 | Rule 威力最大的地方 |
| 口播剪辑 | 脚本解析规范 | CLI 命令行工具 | 断句自然 | 不调 LLM，调产品 |
| 发布 | 平台规范 | 发布 API | 排期约束 | 数据反馈回选题 |
6 个 Agent 流水线，7 条 Rule 全程约束。 上一个 Agent 的输出是下一个 Agent 的输入。
这就是"Agent = Skill + Tool + Rule + Code + Workflow"的实际体现——不是每个 Agent 都需要全部五个部分，但每个 Agent 都是这五个部分的特定组合。
真实案例：用 Agent 写书
同样的模式，写书这条流水线用了 4 个 Agent：
Agent 1: 章节内容 → 按三层结构生成书稿（Skill: qoder-content-write）
Agent 2: 配图编排 → 分析章节 → 规划配图 → 生成 → 插入（组合 3 个 Skill）
Agent 3: 网站发布 → 构建 Vitepress → 上传服务器 → 配置 Nginx
Agent 4: PDF 生成 → 格式转换 → 排版 → 输出（规划中）配图编排 Agent 特别能说明问题——它内部组合了三个 Skill：
| Skill | 用途 |
|---|---|
generate-illustration | 概念配图：对比/网格/流程三种模板 |
product-screenshot | 产品截图：Playwright 自动截图 |
insert-illustration | 配图插入：按先图后文原则插入到正确位置 |
同时受两条 Rule 约束：
- 视觉规范：科技暗色风格、人=紫色/AI=青色/流程=琥珀色
- 先图后文：配图必须出现在文字描述之前
同一个基座，绑上不同的 Skill + Tool + Rule 组合，就变成了不同领域的专业 Agent。
两个案例放在一起看
| 维度 | 自媒体（6 Agent） | 写书（4 Agent） |
|---|---|---|
| 基座 | 同一套 Qoder Agent 基座 | 同一套 Qoder Agent 基座 |
| Harness | 7 条内容创作 Rule | 三层结构 + 配图规范 + 术语统一 |
| Agent 数量 | 6 个（采集→分析→选题→文案→剪辑→发布） | 4 个（内容→配图→发布→PDF） |
| 人的角色 | 决策者，不做执行 | 决策者，不做执行 |
| 输出物 | 短视频 | Web 网站 + PDF |
同一基座，不同领域绑上不同的 Harness（Skill + Rule），就变成了该领域的专业流水线。
这就是 Agent 的本质——不是一个 LLM 调用，是一个有边界、有规矩、有能力的角色封装。
业界怎么做的
同样的"Agent 是什么"问题，其他框架怎么定义？
LangGraph 把 Agent 定义为"图中的一个节点"——Agent 就是 LangGraph 图里的一个处理节点，它接收消息、调用 LLM、可能调工具、输出结果。Agent 的边界就是图的节点边界。这种定义的好处是 Agent 的行为完全可预测（图的边决定了下一步去哪），坏处是 Agent 不能自主决定"下一步做什么"。
微软 Agent Framework (MAF) 把 Agent 定义为"ChatClientAgent"——一个拥有 ChatClient、Tools、Instructions 的独立实体。Agent 的边界由它的 Tools 和 Instructions 决定——有什么工具就能做什么事，有什么指令就按什么规矩做。多 Agent 通过"Agent 组合"实现——一个 Agent 可以包含其他 Agent。
AgentScope Java 把 Agent 定义为"消息处理器"——Agent 接收消息、处理、输出。Agent 之间通过 Pipeline 组合（串行、并行、条件分支）。这种定义的好处是 Agent 之间完全解耦，坏处是 Agent 的"角色感"较弱——它更像一个函数而不是一个角色。
Hermes 把 Agent 定义为"Skill 集合 + 系统提示词"——Agent 的能力边界由它能访问的 Skill 决定。新增一个 Skill，Agent 就多一个能力。这种定义的好处是 Agent 能力可以动态扩展，坏处是 Agent 的边界不够清晰——Skill 多了之后 Agent 可能“什么都会一点但什么都不精”。
| 框架 | Agent 是什么 | 边界由什么决定 | 多 Agent 怎么协作 |
|---|---|---|---|
| LangGraph | 图中的一个节点 | 图的边（条件分支） | 子图 |
| MAF | ChatClientAgent 实体 | Tools + Instructions | Agent 组合 |
| AgentScope | 消息处理器 | Pipeline 结构 | 消息管道 |
| Hermes | Skill 集合 + 提示词 | 可访问的 Skill | 工具自动发现 |
| 我的设计 | 角色封装 | Prompt + Tool + Skill + Rule + Model | Lead-Sub 分层 |
我的设计最接近 MAF，但多了一层“角色封装”的概念——每个 Agent 不只是一个处理节点，是一个有名字、有边界、有规矩的“角色”。这也是为什么我用 Lead-Sub 分层而不是 Pipeline——角色之间有明确的上下级关系，不是平等的消息传递。
关键认知
Agent 不是"调一次 LLM"，是"一个完整角色的封装"。
一个 Agent = System Prompt（你是谁）+ Tool（你能做什么）+ Skill（你怎么做）+ Rule（你不能怎么做）+ Model（用什么脑子）。
这五个部分的不同组合，产生了不同领域的专业 Agent。
但一个 Agent 能做的事是有限的。当任务复杂到需要一个 Agent 做不完时，就需要多个 Agent 协作——一个 Agent 理解意图、拆分任务，分配给其他 Agent 执行。
这就是下一节要讨论的：我的产品里，自定义 Agent 和自定义 Tool 是怎么设计的。