第 1 章：为什么需要 Agent
本章导读
- 核心问题：为什么软件工程需要从 Prompt 走向 Agent。
- 关键词：Agent、Workflow、动态控制流、工具反馈、验证循环
- 学习产出：判断哪些任务值得引入 Agent，并理解 CI 失败分析为什么是合适的 MVP。
1. 本章要解决什么问题
过去几年，很多团队学习 LLM 应用开发，都是从 Prompt Engineering 开始的。
这种路径很自然：
写一个 Prompt
↓
让模型完成一个任务
↓
调整措辞
↓
得到更好的结果
但当任务开始变复杂时，单个 Prompt 很快会遇到边界。例如：
- 用户的问题需要读取多个文档；
- 任务需要调用外部 API；
- 需要根据中间结果决定下一步；
- 需要检查输出是否正确；
- 需要在失败后重试；
- 需要修改代码、运行测试、修复错误；
- 需要连续工作几十分钟甚至几个小时。
这时问题已经不再是“Prompt 怎么写得更好”，而是：
如何构建一个能够感知环境、调用工具、根据反馈调整行为，并持续推进任务的软件系统？
这就是 Agent 出现的原因。
本章重点回答五个问题：
- Prompt 的根本局限是什么；
- Workflow 为什么是通向 Agent 的中间形态；
- Anthropic 如何定义 Agent；
- Agent 与普通自动化流程有什么区别；
- 为什么 Tool Use 是 Agent 能力扩展的关键。
2. 对应 Anthropic 文章
本章主要对应 Anthropic Engineering 的文章：
- Building Effective Agents
这篇文章的重要性在于，它没有把 Agent 描述成一个神秘概念，而是把 Agent 拆解成几个工程上可以理解的层次：
Augmented LLM
↓
Workflow
↓
Agent
也就是说，Agent 不是凭空出现的，也不是一个“更聪明的 Prompt”。它是从普通 LLM 调用逐渐增加外部能力、控制流程和反馈循环之后形成的一种系统形态。
3. 原文核心观点
从工程角度看，这篇文章有几个关键观点。
3.1 不要一开始就构建复杂 Agent
Anthropic 反复强调一个原则：
成功的 LLM 系统，不是越复杂越好，而是越适合问题越好。
如果一个简单 Prompt 可以解决问题，就不需要 Workflow。
如果一个固定 Workflow 可以解决问题，就不需要 Agent。
只有当任务本身具有开放性、动态性和不确定性时，Agent 才真正有价值。
这对企业开发尤其重要。很多团队刚开始做 AI 应用时，容易直接上来就设计：
Planner
Executor
Memory
Tool Registry
Multi-Agent
Reflection
但如果业务场景只是“根据固定模板生成报告”，这种架构反而会增加成本、延迟和不可控性。
3.2 Agentic System 的基础单元是 Augmented LLM
Anthropic 把增强后的 LLM 称为 agentic system 的基础构件。
所谓增强，主要包括：
LLM
+ Retrieval
+ Tools
+ Memory
普通 LLM 只能基于输入上下文生成文本。
增强后的 LLM 可以：
- 检索外部信息；
- 调用工具；
- 读取和写入记忆；
- 根据工具返回结果继续推理。
这一步非常关键，因为它把 LLM 从“文本生成器”推向了“任务执行器”。
3.3 Workflow 是固定控制流
Workflow 是一种更受控的 agentic pattern。
它的特点是：
流程由开发者预先定义
模型在流程中的某些节点发挥作用
系统整体路径相对固定
例如：
用户输入
↓
分类
↓
路由到不同 Prompt
↓
生成答案
↓
校验
↓
返回结果
在 Workflow 中，模型很重要，但模型不是完全自由行动的。真正控制流程的是程序。
3.4 Agent 是动态控制流
Agent 与 Workflow 最大的区别在于：
Agent 可以根据任务进展、工具结果和环境反馈，动态决定下一步做什么。
一个典型 Agent 循环大致是：
理解任务
↓
制定计划
↓
选择工具
↓
执行动作
↓
观察结果
↓
评估进展
↓
继续 / 修正 / 停止
在这个过程中，控制流不再完全由开发者预先写死，而是部分交给模型根据上下文进行决策。
这也是 Agent 强大的地方，同时也是 Agent 危险的地方。
3.5 Tool 是 Agent 的手脚
没有工具的 Agent，本质上只能“想”和“说”。
有了工具之后，Agent 才能：
- 搜索资料；
- 读取文件；
- 修改代码；
- 查询数据库；
- 调用业务系统；
- 执行测试；
- 访问 Git、Jira、Confluence、CI/CD 等企业系统。
因此，Agent 的能力不只取决于模型本身，也取决于工具接口是否清晰、稳定、可组合、可验证。
这也是后续 Tool Engineering 章节要重点讨论的内容。
4. 工程视角重新解释
从软件工程角度看，Agent 的出现不是偶然的。
它是大语言模型从“单次推理”走向“持续任务执行”的必然结果。
4.1 Prompt 解决的是单次认知问题
Prompt Engineering 主要解决的是：
如何让模型在一次调用中更好地理解意图并生成答案
典型场景包括：
- 改写文本；
- 总结文章；
- 生成 SQL；
- 解释代码；
- 写一封邮件；
- 根据模板生成内容。
这些任务的共同特点是：
输入相对完整
目标相对明确
过程不需要太多外部反馈
一次或少数几次调用即可完成
此时 Prompt Engineering 很有效。
4.2 Workflow 解决的是固定流程问题
当一个任务可以拆成多个明确步骤时，就进入 Workflow 阶段。
例如客服系统：
识别用户意图
↓
判断问题类型
↓
选择知识库
↓
生成回答
↓
检查合规性
↓
返回答案
这种任务虽然比单个 Prompt 复杂，但路径仍然比较清楚。
此时最好的方案通常不是 Agent，而是 Workflow。
因为 Workflow 更容易：
- 调试；
- 监控；
- 测试；
- 限制风险；
- 控制成本；
- 满足企业合规要求。
4.3 Agent 解决的是开放式任务问题
Agent 适合处理这类任务：
目标明确，但完成路径无法提前完全确定
例如：
- 修复一个未知原因的线上 Bug；
- 给一个大型代码库增加新功能；
- 调研一个复杂技术方案；
- 分析多份文档并形成决策建议；
- 自动排查 CI 失败原因；
- 在多个企业系统之间完成跨系统任务。
这些任务有一个共同点：
你可以描述最终目标，但很难提前写死每一步。
例如“修复测试失败”这个任务，Agent 可能需要：
读取失败日志
↓
定位失败测试
↓
搜索相关代码
↓
理解业务逻辑
↓
修改实现
↓
重新运行测试
↓
如果失败，继续分析
↓
直到通过或遇到阻塞
这里的每一步都依赖上一步的结果。
这正是 Agent 的适用场景。
5. 架构图 / 流程图
5.1 从 Prompt 到 Agent
5.2 Agent 的基本循环
5.3 Workflow 与 Agent 的控制权差异
6. Java / Spring Boot 落地方案
本书后续会持续构建一个企业研发 Agent 平台。这里先给出最小模型。
6.1 最小 Agent 模型
一个最小 Agent 至少需要以下模块：
Task
Agent
Context
Tool
Observation
Decision
StopCondition
对应到 Java，可以先抽象为：
public interface Agent {
AgentResult run(AgentTask task);
}
任务对象：
public record AgentTask(
String id,
String objective,
Map<String, Object> metadata
) {}
工具接口：
public interface AgentTool {
ToolDefinition definition();
ToolResult execute(ToolInput input);
}
Agent 每一轮执行可以抽象为：
public record AgentStep(
int index,
String thought,
String action,
ToolResult observation
) {}
最终结果：
public record AgentResult(
String taskId,
AgentStatus status,
String summary,
List<AgentStep> steps
) {}
这不是完整实现，只是表达一个核心思想：
Agent 不是一次 LLM 调用，而是一组有状态的执行步骤。
6.2 最小运行流程
用户提交任务
↓
AgentSession 创建
↓
ContextManager 组装初始上下文
↓
LLM 生成下一步动作
↓
ToolExecutor 执行工具
↓
Observation 写回上下文
↓
StopCondition 判断是否结束
对应到 Spring Boot 模块，可以先设计：
agent-core
Agent
AgentTask
AgentResult
AgentSession
agent-context
ContextManager
ContextProvider
ContextWindow
agent-tool
AgentTool
ToolRegistry
ToolExecutor
agent-runtime
AgentRunner
StopCondition
StepRecorder
6.3 一个极简的 AgentRunner
下面是伪代码级别的结构：
public class AgentRunner {
private final LlmClient llmClient;
private final ContextManager contextManager;
private final ToolExecutor toolExecutor;
private final StopCondition stopCondition;
public AgentResult run(AgentTask task) {
AgentSession session = AgentSession.start(task);
while (!stopCondition.shouldStop(session)) {
AgentContext context = contextManager.build(session);
AgentDecision decision = llmClient.nextAction(context);
if (decision.isFinalAnswer()) {
return session.complete(decision.finalAnswer());
}
ToolResult result = toolExecutor.execute(decision.toolCall());
session.record(decision, result);
}
return session.stopped("Reached stop condition");
}
}
这个结构看起来简单，但它已经包含 Agent 的核心：
上下文
↓
决策
↓
行动
↓
观察
↓
循环
后续章节中的 Context Engineering、Tool Engineering、Memory、Harness，本质上都是在增强这个循环。
7. 与其他框架对比
7.1 与传统工作流引擎对比
传统工作流引擎，例如 BPMN、Camunda、Activiti，擅长处理：
流程稳定
节点清晰
审批规则明确
异常路径可枚举
Agent 擅长处理：
路径不确定
中间状态复杂
需要动态搜索和判断
需要根据环境反馈调整行动
所以 Agent 不应该替代所有工作流。
更合理的方式是：
稳定流程用 Workflow
开放问题用 Agent
企业系统中二者结合
7.2 与 LangGraph 对比
LangGraph 强调用图结构组织 LLM 应用。
它适合表达：
- 多节点流程；
- 条件跳转；
- 状态机；
- 可恢复执行；
- 多 Agent 协作。
从本书视角看，LangGraph 更接近一种 Agent Runtime / Workflow Runtime 的实现方式。
但无论使用什么框架，核心问题仍然是：
哪些流程应该固定，哪些决策应该交给模型？
7.3 与 Claude Code / Codex / Pi Agent 对比
Claude Code、Codex、Pi Agent 这类编码助手，本质上都是 Coding Agent。
它们的核心能力不是“生成代码”，而是：
理解代码库
↓
规划修改
↓
编辑文件
↓
运行命令
↓
读取错误
↓
继续修复
这正是 Agent 循环在软件开发场景中的体现。
8. 常见误区
8.1 误区一：Agent 越复杂越高级
不是。
Agent 的复杂度应该由任务复杂度决定。
如果简单 Prompt 可以解决，就不要上 Workflow。
如果 Workflow 可以解决，就不要上 Agent。
8.2 误区二：Agent 等于 Multi-Agent
不是。
单 Agent 已经可以完成很多复杂任务。
Multi-Agent 是更高复杂度的组织方式，适合需要角色分工、并行探索、互相评审的任务。
8.3 误区三：Agent 可以完全自主，不需要边界
企业环境中，Agent 必须有边界：
- 权限边界；
- 工具边界；
- 成本边界；
- 时间边界；
- 数据边界；
- 人工确认点。
没有边界的 Agent，不是智能，而是风险。
8.4 误区四：只要模型足够强，就不需要工程
恰恰相反。
模型越强，越需要工程系统把它的能力安全、稳定、可控地释放出来。
Agent 的可靠性来自：
模型能力
+ 上下文质量
+ 工具设计
+ 验证机制
+ 执行边界
+ 可观测性
9. 贯穿案例：CI 失败分析 Agent
在本书的贯穿案例中，我们选择“CI 失败分析 Agent”作为第一个企业研发 Agent 场景。
这个任务的用户目标是：
请分析 build #4312 为什么失败。
只允许读取 CI 日志、代码、Git Diff 和项目文档，不要修改文件。
请输出失败原因、证据、可能相关文件、建议修复方向和置信度。
它非常适合用来理解为什么需要 Agent。因为 CI 失败原因并不固定，可能来自测试失败、编译错误、依赖问题、环境问题、代码变更或基础设施波动。
如果只是简单总结日志，Prompt 可能足够；如果失败类型固定，Workflow 可能足够。但当系统需要根据日志内容动态决定是否搜索代码、读取 Git Diff、查看测试文件、检索历史类似失败时，就进入了 Agent 的适用范围。
在这个案例中，Agent 的基本循环是：
读取 CI 失败摘要
↓
判断失败类型
↓
选择工具读取 Git Diff 或代码片段
↓
观察工具结果
↓
形成根因假设
↓
用证据验证假设
↓
输出分析报告
这个案例会贯穿后续章节，用来说明 Context、Tool、Skill、Harness、Memory、MCP、Multi-Agent 和 Runtime 如何共同构成一个企业级 Agent 系统。
10. 本章小结
本章讨论了为什么需要 Agent。
核心结论有五点：
- Prompt Engineering 适合单次或短链路任务，但难以处理长流程、动态决策和外部反馈。
- Workflow 是从 Prompt 到 Agent 的中间形态，适合流程相对固定的任务。
- Agent 适合目标明确但路径不确定的开放式任务。
- Tool Use 让 Agent 从“会说”变成“能做”。
- 企业级 Agent 的关键不是追求复杂，而是在 Prompt、Workflow、Agent 之间选择合适抽象。
可以用一句话总结本章：
Agent 不是一个更长的 Prompt，而是一个围绕目标、上下文、工具、观察和反馈循环构建的软件系统。
11. 实践任务
请尝试完成下面的小练习。
任务 1：判断是否需要 Agent
列出你所在团队的 5 个 AI 应用场景，并将它们分类为：
Prompt 即可
Workflow 更合适
Agent 才有价值
先用下面三个问题完成初步分类：
- 输入信息是否完整；
- 执行流程是否固定；
- 是否需要根据工具反馈动态决定下一步。
将你的判断记录下来，并在第 2 章使用完整决策矩阵复核。这里先建立直觉，不重复展开 Workflow 与 Agent 的详细边界。
任务 2：设计最小 Agent Loop
用你熟悉的语言写一个伪代码，实现下面循环：
接收任务
↓
构造上下文
↓
让模型决定下一步
↓
如果需要工具，则调用工具
↓
把工具结果写回上下文
↓
判断是否完成
要求先不要引入 Memory、Multi-Agent、复杂 Planner。
只实现最小闭环。
任务 3：为企业研发 Agent 选择第一个场景
如果要构建本书中的贯穿案例“企业研发 Agent 平台”，请从下面场景中选择一个作为第一个 MVP：
- 自动总结 Issue；
- 根据错误日志定位可能代码位置；
- 自动生成单元测试；
- 自动修复简单 Checkstyle / Lint 问题；
- 自动分析 CI 失败原因。
建议优先选择：
自动分析 CI 失败原因。
因为它天然包含 Agent 的基本要素：
日志输入
↓
上下文检索
↓
工具调用
↓
多轮分析
↓
结论输出
但它的风险又相对可控，不会一开始就让 Agent 自动修改生产代码。