第 1 章：什么是 Agent，什么不是

很多人把“agent”理解成更聪明的模型，但官方材料强调的重点其实是“决策权在哪里”。workflow 预先写好步骤，模型只在步骤里执行；agent 则是在运行时判断下一步该做什么、是否需要工具、何时停下。换句话说，agent 的核心不是语言能力，而是“能否在不确定环境中自我推进”。[42]

这一区别决定了系统设计的重心。workflow 更像工艺流程图，稳定、可回放；agent 更像一个有目标的执行者，会探索、试错、回退。后者需要更多控制面：它不能只有一个提示词，还需要工具、权限、日志、回滚等工程设施。若这些设施缺失，模型看起来能做事，但行为不可控，难以复盘。[19][42]

官方研究里对 agent 的一个简明定义是“模型在循环中自主使用工具”。这个定义有两个关键词：自主和循环。自主意味着模型不是被动被调用，而是根据上下文决定行动；循环意味着任务不是一步完成，而是持续迭代直到满足条件。这个循环就是后面 Agent SDK 与 Claude Code 运行时的核心结构。[64][19]

把 agent 视作一个“可以运行很久的进程”会更容易理解它的工程需求。它需要持续吸收信息、做出选择，并留下一些可解释的痕迹。研究文章反复强调：越是复杂的任务，越不应该用一条长 prompt 解决，而是把任务拆成多轮，允许模型在工具和外部世界之间往返。[42]

这也解释了“什么时候不该用 agent”。当任务流程高度确定、步骤稳定时，workflow 更简单也更可靠。把这种任务交给 agent 会引入不必要的随机性，还会放大工具调用与上下文管理的成本。官方材料的态度更接近“先用最简单的结构”，只有当流程无法预定义时才引入 agent。[42]

理解 agent 的本质还有一个收益：你可以把它当作“被治理的执行者”。治理并不意味着束缚，而是把它放在清晰的边界内工作。工具的输入结构、权限范围、运行时的检查点，都属于治理的一部分。没有这些边界，agent 会变成“语言驱动的脚本”，看似灵活，实则脆弱。[4][19]

因此，本书后续章节的逻辑顺序不是偶然的：先明确 agent 与 workflow 的差异，再讨论工具契约与技能结构，再进入运行时与 MCP 协议。只有把这些层次串起来，agent 才会从“会说话的模型”变成“可控的系统组件”。[42][4][19][16]