一个 Agent 由什么构成

一句话理解：Agent = 模型 + 一整套让它能看见、能动手、能停下、能被信任的零件；模型只是其中最显眼的一个。

很多团队做 Agent 的第一步是“选个最强的模型，写一段 Prompt”，然后发现 Demo 很惊艳、上线就翻车：查错了数据、调错了接口、做到一半卡住、用户不敢放手。原因通常不在模型，而在模型之外那十几个没被设计过的零件。

这一课把 Agent 拆开，给你一张“零件清单”。后面每个模块都会深入其中一两个零件；现在的目标是建立全局地图，拿到任何 Agent 需求时，能逐项问出“这一块谁来设计”。

用一个例子贯穿：客服工单处理 Agent

设想客服同学输入一句话：“订单 A1234 的客户说已经付了钱，但订单还显示未支付，帮我查一下怎么回事并处理。”

一个合格的 Agent 大致会这样工作：

图 1 · 客服工单 Agent 的一次任务：每一步都用到了不同的零件

这短短几步，已经用到了下面表格里的几乎所有零件。

十二个零件

零件	它回答的问题	在客服工单 Agent 里的样子	深入学习
Model 模型	用哪个“大脑”做判断	主流程用强模型，分类小任务用小模型	模型选型与路由
Instructions 指令	它是谁、目标是什么、边界在哪	“只能创建工单，退款必须转人工”	一份好指令的构成
Context 上下文	此刻让模型看到什么	订单信息 + 相关 SOP，而不是整个知识库	什么是 Context
Knowledge 知识	企业自己的资料从哪来	售后处理手册、退换货政策条款	RAG 全流程
Tools 工具	能对外部系统做什么	查订单、查支付状态、建工单、发通知	Function Calling 原理
Skills 技能	复杂任务按什么方法做	“支付状态不一致排查 SOP”打包成可加载的能力	Skill 是什么
执行环境	动作在哪里、以什么方式发生	通过 API 调内部系统；个别老系统只能用浏览器操作	三种执行方式
Loop 循环	下一步怎么定、什么时候停	查一步、看结果、再决定查什么，查清即停	初识 Agent Loop
Memory 记忆与状态	记得做到哪、记得用户是谁	昨天查到一半的工单，今天能接着查	状态的五种类型
权限与护栏	能不能做、该不该做	查询自动执行，改状态需确认，退款禁止	操作分级
Evals 评估	怎么知道它做得好不好	100 个历史工单案例，看诊断准确率	为什么 Agent 必须做 Evals
UX 体验	人如何监督、确认、接管	任务页展示计划、证据、待审批动作	从聊天到监督

注意两点：

前六个零件决定“能力上限”：它能想明白什么、能做到什么。
后六个零件决定“能不能上线”：它会不会乱来、出错了能不能发现、用户敢不敢用。

Demo 阶段大家只做前六个；产品阶段真正花时间的是后六个。

零件之间怎么协作

把零件按“一次任务的生命周期”排起来，就能看清它们的位置关系：

图 2 · 十二个零件的全景关系：Context 是汇合点，护栏在模型之外，Loop 与 Harness 把零件粘在一起

几个容易忽略的关系：

Context 是其他零件的“汇合点”。 Knowledge、Memory、Skill 说明、工具结果，最终都要以上下文的形式进入模型。上下文设计得差，前面的零件做得再好也白费。
权限与护栏必须在模型之外。 模型决定“想做什么”，程序决定“能不能做”。把“不许退款”只写在 Prompt 里，等于把安全交给概率。
Loop 与 Harness 是粘合剂。 调度工具、管理上下文、处理报错、记录日志的那层程序，统称 Harness，下一课之后的模型与 Harness 会专门讲。

不同形态的 Agent，零件权重不同

不是每个 Agent 都要把十二个零件做到满分。按场景调整投入：

场景	最关键的零件	可以简化的零件
Coding Agent	工具（终端、文件、Git）、执行环境（沙箱）、验证（跑测试）	Knowledge（代码仓库本身就是上下文）
SEO 诊断 Agent	Skills（诊断方法论）、工具（抓取、搜索数据）、输出产物	权限（大多是只读操作）
销售分析 Agent	工具（查数）、上下文（指标口径）、证据展示	Memory（多为一次性分析）
客服工单处理 Agent	权限与审批、验证、工具设计	多模态（主要是结构化数据）

判断规则很简单：哪里出错代价最大，就在哪里多投入。 能改线上数据的 Agent，权限和验证要优先；只读的分析 Agent，上下文与证据更重要。

常见误区

“换个更强的模型就好了。” 大部分线上失败来自上下文缺失、工具返回太乱、没有验证，而不是模型不够聪明。先看 Trace 再下结论。
“Prompt 写得够细，就不需要权限系统。” Prompt 是建议，权限是强制。凡是出错代价高的规则，都要由程序执行。
“Evals 和 UX 是上线后再补的。” 没有评测集就无法判断改动是变好还是变坏；没有监督界面，用户不会把真实任务交给 Agent。它们应该和工具一起设计。

产品经理检查清单

拿到一份 Agent 方案时，逐项追问：

模型：主流程和子任务分别用什么模型？为什么？
指令：目标、边界、禁止事项写清楚了吗？哪些规则由程序强制执行？
上下文：每一步模型会看到哪些信息？有没有该给没给、不该给却给了的？
知识：企业资料从哪来、多久更新、谁有权看？
工具：列出全部工具，哪些是只读，哪些会写入？
执行环境：通过 API、浏览器还是代码沙箱执行？
循环：最多执行多少步？什么情况下停止？
记忆：跨会话需要记住什么？用户能否查看和删除？
权限：哪些操作自动执行，哪些需要确认，哪些禁止？
评估：用什么样本、什么指标衡量成功？
UX：用户在哪里看进度、看证据、做审批、接管任务？

练习

选一个你熟悉的业务任务（例如“每周 SEO 诊断报告”或“月度销售下滑分析”），用 30–45 分钟完成：

按上面的十二个零件，逐项写出这个 Agent 需要什么，写不出来的标注“待定”。
圈出你认为出错代价最大的 3 个零件，写出各自最坏情况。
对每个“待定”项，写一个你要去问研发或业务方的问题。

完成后你会发现：真正难回答的，往往不是“用哪个模型”。

下一步

零件清单里有几个词最容易混淆：Agent、Skill、Tool 与 Workflow。下一课「Agent、Skill、Tool 与 Workflow」用一句话分清它们。

一个 Agent 由什么构成