到底什么是 Agent · caiwei.online

开始动手之前先回答一个被讲烂但 rarely 讲清的问题：什么才算 Agent？ 这不是文字游戏——它决定你接下需求后是写一段确定性脚本，还是启动一个带工具的循环。

:::info 学习目标完成本篇后你能够：用「控制流在谁手里」判断一个系统是 workflow 还是 agent；在 agent 化光谱上定位一个产品的位置；对任意需求给出”该不该上 agent”的判断及理由。前置：无。预计时长：30 分钟。 :::

:::note 本章术语速查（新手建议先读）

Agent（智能体）：让大模型自己决定”做什么、怎么做、何时结束”的程序。你给它目标和工具，它自己规划路径。
Workflow（工作流）：和 agent 相反——每一步做什么由开发者写死，大模型只是流程中的”工人”。
Function Calling（函数调用）：大模型的一项能力——你告诉它有哪些函数可用，它返回”我想调用某个函数及参数”，由你的代码真正执行。
Coding Agent：专门干编程活的 agent（改代码、跑测试、修 bug），Codex 和 dsh 都是。
控制流：程序执行的顺序。“控制流在谁手里”= 是你的代码决定下一步，还是模型决定。 :::

Anthropic 的分界：workflow 与 agent

Building Effective Agents 给出了目前最实用的定义：

Workflow（工作流）：开发者预先写死了 LLM 和工具的调用流程。LLM 在流程节点里，但控制流是你的代码。
Agent（智能体）：LLM 自己决定调什么工具、调几次、何时结束。控制流交给了模型，你只提供工具、指令和终止护栏。

判据一句话：把 LLM 换成一个实习生，你发的是”流程说明书”还是”目标 + 权限”？ 前者是 workflow，后者是 agent。

agent 化是一条光谱，不是开关

实践中很少有非黑即白。工程实践中常见的五种模式，按”模型自主程度”排成一条光谱（前四种的命名源自 Anthropic 的归纳）：

前三种本质是 workflow（模式由你选定），后两种才需要真正的 agent 循环。选型的本质是在”可控性”与”灵活性”之间定价：每向右移一格，你获得处理未知路径的能力，同时付出不可预测性、成本与安全的代价。

最小定义：模型 + 工具 + 循环 + 终止条件

剥掉所有营销词，一个 agent 只由四件东西构成：

模型：决策中枢；
工具：模型能调用的能力（读文件、跑命令、发请求）；
循环：调用工具 → 结果回填 → 再次请求，直到完成；
终止条件：模型说完成了、轮次上限、预算上限、人工打断。

本专栏的两大解剖对象都是这四件东西的工业级实现，而且做的是同一类 agent——coding agent。这不是巧合：

Codex：OpenAI 的开源 coding agent。Rust 编写，codex-rs 下 145 个 crate 分六层（客户端 / 核心循环 / 工具执行 / 安全 / 持久化 / 扩展），形态是终端 TUI + 无头 exec + 面向 IDE 的 JSON-RPC 服务。
DeepSeek Harness（dsh）：DeepSeek 开源的 agent harness（MIT）。TypeScript + Cordis 插件框架，“一切皆插件”——连 agent 循环本身都是可替换的插件；形态同样是 web + headless + SDK 三件套。

两者的循环内核就是第 4 篇要手写的东西，但它们 99% 的代码花在别处。先记住这个比例。

什么时候不该用 Agent

专栏反复强调的工程判断（也是 Anthropic 专文的核心建议）：能用 workflow 解决的，不要用 agent。三个具体的”不要”：

路径已知：如果每一步都可以写死（抽取 → 清洗 → 入库），写 workflow。确定性流程的可测试性、成本、延迟全面优于 agent；
零容错：一次错误回答代价极高的场景（直接执行生产变更），先上 workflow + 人工节点，把 agent 限定在”建议者”角色；
只需要一个工具的一次调用：这是 function calling，不是 agent——不需要循环，也就不需要 agent 的全部复杂度。

有意思的是，两个被解剖对象自己也在践行这条克制原则——它们的架构里处处是”反 agent 化”的结构化设计：

Codex 的任务系统里除了常规 agent 任务（RegularTask），还保留 Compact（压缩）、Review（审查）等专用任务类型——能结构化的部分就不交给模型自由发挥；
dsh 内建 workflow 能力（workflow 工具族 + 计划模式 plan），让确定性的多步流程以代码而非自然语言定义，计划模式的进入/退出都有评审机制。

什么时候必须用 Agent

反过来，满足这些条件时 workflow 无法胜任：

路径无法预知：修复一个未知原因的 bug、在陌生仓库里找代码——下一步取决于上一步的发现；
需要组合不可枚举的工具调用：可能的动作序列是组合爆炸的，写死流程等于写死失败；
任务有明确完成判据但无固定路径：「让测试通过」「把这个需求实现掉」。

coding agent 恰好是这个象限的极致样本：输入是自然语言需求，路径完全依赖代码库探索的每一步发现。这也是为什么它成了 agent 工程模式的孵化器——本专栏后续的所有主题（上下文管理、压缩、审批、沙箱、评测）都是 coding agent 倒逼出来的工程。

与其他主题的联系

循环的具体实现是第 4 篇的主题，两个系统的循环源码对照见番外第 16 篇；
终止条件的工程形态（turn/end 原因枚举、步数上限）在第 4、15 篇展开；
“模型自主度”的代价由安全体系兜底——第 12 篇的审批与沙箱，就是给光谱右端的模式系上安全绳。

本篇产出：一份判断练习

拿你手头的三个真实需求，每个写下三行答案：控制流能否预先写死？完成判据是什么？容错多少？ 验收标准：能对每一个明确说出”agent / workflow / function calling 即可”三者之一的结论与依据，并标出它在光谱上的位置。写完和同事辩论五分钟——判断分歧最大的那个需求，往往最值得继续讨论。

自测三题

一个”LLM 翻译 → 拼接模板 → 再让 LLM 润色”的固定管线，是 agent 吗？（不是——控制流写死，是 workflow，位于光谱最左端）
agent 与 function calling 的区别是什么？（function calling 只有一次调用往返；agent 把它装进循环、由模型自主决定下一步与何时结束）
你的 agent 需要访问生产数据库。第一反应不该是”接上”，而该是什么？（先问权限边界：只读？白名单查询？审计？——这正是第 12 篇的主题）

下一篇开始动手：先把 LLM API 这块地基打牢。