7. Agent：让 AI 执行多步骤任务

7.1 Agent 是什么

Agent 是能够围绕目标进行多步骤规划、调用工具、观察结果、调整行动并完成任务的 AI 系统。

产品视角公式：

Agent = Model + Memory + Planning + Tool Use + Runtime / Harness + Guardrails

也可以简化为：

Agent = 模型 + 驾驭系统

模型负责理解和生成，驾驭系统负责上下文、工具、权限、记忆、执行、验证和安全。

7.2 Agent 与 Workflow 的区别

维度	Workflow	Agent
流程	预先设计	可动态规划
路径	固定或半固定	根据任务变化
可控性	强	相对弱，需要治理
适合场景	标准业务流程	开放复杂任务
风险	较低	较高
产品重点	节点设计	工具、权限、记忆、验证

产品判断：

流程明确、规则固定：优先 Workflow。
任务开放、多步骤、路径不确定：考虑 Agent。
高风险动作：Agent 只建议，不直接执行，必须人审。

7.3 Agent 三层架构

层级	核心问题	产品经理关注点
Control 控制层	谁说了算？	用户授权、权限边界、人工确认、策略规则
Agency 代理层	Agent 能做什么？	工具清单、任务边界、可访问数据、可执行动作
Runtime 运行层	如何持续运行？	上下文管理、任务状态、日志、重试、失败恢复

7.4 Agent 常见范式

7.4.1 ReAct

ReAct = Reasoning + Acting。
模型一边思考，一边调用工具，再根据工具结果继续行动。

适合：

搜索问题。
多步查询。
工具调用。
数据分析。

风险：

工具调用过多。
路径发散。
结果不稳定。

7.4.2 Plan-and-Solve

先制定计划，再逐步执行。

适合：

任务路径较清晰。
需要高效执行。
需要展示执行计划。

风险：

初始计划错了，后续全错。
不适合高度动态的任务。

7.4.3 Reflection

执行后进行反思、自检、修正。

适合：

写作润色。
代码修复。
文档审查。
质量要求高的输出。

风险：

反思不等于真实验证。
可能反复修改但没有实质提升。

7.4.4 Multi-Agent

多个 Agent 分工协作，例如规划者、执行者、评审者。

适合：

复杂任务。
需要角色分工。
需要评审和复核。

风险：

成本高。
协作链路复杂。
责任边界不清。

7.5 Agent 工程的核心：Harness

Harness 可以理解为“驾驭系统”，是模型之外的一整套控制系统。

它包括：

上下文工程。
工具注册与调用。
权限控制。
文件系统隔离。
状态管理。
记忆管理。
日志追踪。
任务队列。
验证器。
人工审批。
回滚机制。
成本限制。

7.6 上下文工程：Agent 的核心战场

Agent 不是只靠模型强，而是靠“每一步让模型看到正确的信息”。

上下文工程四个动作：

动作	说明	示例
Write 写入	把重要状态写入可持久化位置	任务计划、决策记录、执行日志
Select 选择	只把当前任务需要的信息放进上下文	相关文件、相关历史、相关工具
Compress 压缩	把长历史压缩成摘要	会话摘要、阶段总结
Isolate 隔离	子任务隔离，避免互相污染	子 Agent、临时目录、沙箱

7.7 Agent 常见问题与解法

问题	症状	解法
上下文腐化	对话越长越混乱	外部记忆、任务状态、阶段摘要
错误累积	前面错了后面继续错	检查点、回滚、验证器
一次性做完	漏项、质量差	拆成小任务，逐步验收
过早宣布完成	没做完就说完成	明确完成标准和自检清单
工具滥用	频繁调用无关工具	工具白名单、调用预算
越权操作	访问或修改不该动的数据	权限分级、人工确认
成本失控	多轮循环调用模型	预算上限、停止条件

7.8 Agent 验证与质量门控

推荐闭环：

Planner 制定计划
→ Generator 执行任务
→ Evaluator 评估结果
→ 不合格则修复
→ 通过则输出
→ 全程日志留痕

常见验证方式：

Schema 校验。
引用来源校验。
单元测试。
E2E 测试。
Playwright 浏览器测试。
人工审核。
事实一致性检查。
安全策略检查。

7.9 Agent 外部接口能力

接口	作用	产品经理理解
文件系统	读写本地文件	风险高，需要权限控制
HTTP REST API	调用业务系统接口	企业最常见集成方式
WebSocket	实时双向通信	实时状态、协作场景
SSE	服务端持续推送	流式输出、任务进度
Function Calling / Tool Use	模型调用函数	工具输入输出必须结构化
MCP	标准化连接数据源和工具	类似 AI 应用的标准接口层
Computer Use	操作屏幕和 GUI	通用但不够稳定，风险高
Browser Control / CDP / Playwright	精准控制浏览器	Web 自动化、测试、采集
A2A / Agent-to-Agent	Agent 之间通信	多 Agent 协作和任务分发

7.10 Computer Use 与浏览器操控的区别

对比项	Computer Use	浏览器操控 / CDP / Playwright
原理	看屏幕、点按钮、键盘操作	直接操控 DOM / 浏览器协议
精度	依赖视觉识别	元素级精确
范围	任意 GUI 应用	浏览器内应用
稳定性	较弱	较强
代表场景	通用桌面操作	Web 自动化、测试、采集

7.11 v1.2 增强：Agent 工程化概念索引

v1.1 已经说明 Agent 的基本形态：规划、记忆、工具调用、运行时、上下文工程、权限与验证。v1.2 在这个基础上补齐“Agent 工程化落地”的关键概念，不改变原 Agent 章节的判断：能用 Workflow 解决的，不要优先上复杂 Agent；必须用 Agent 时，要先设计控制系统，再设计模型提示词。

7.11.1 Agent Hardness：任务复杂度分级

Agent Hardness 用来判断一个场景需要多复杂的智能体能力。

等级	类型	推荐实现	产品判断
L0	普通问答	LLM / RAG	不需要 Agent
L1	单次工具调用	Function Calling / MCP Tool	模型只需要选择一个工具
L2	固定多步骤流程	Workflow	路径固定，优先流程编排
L3	动态路径、多工具选择	轻量 Agent	任务路径不固定，但风险可控
L4	长任务、状态记忆、中途恢复	Agent + Harness	需要任务状态、日志、恢复、验证
L5	高风险跨系统执行	Agent + 权限 + 人审 + 审计 + 回滚	涉及资金、权限、生产系统、法律责任

核心原则：Agent Hardness 越高，越不能只靠 Prompt，必须增加 Harness、权限、验证、审计、回滚和人工确认。

7.11.2 Agent Harness：运行时控制层

Harness 是模型之外的运行时控制系统，解决 Agent 如何被控制、被观察、被验证、被回滚。

产品经理需要把 Harness 拆成以下组件：

Agent Harness
├─ 任务状态管理
├─ 上下文选择与压缩
├─ Tool / MCP 接入
├─ Skill 加载与触发
├─ Instruction / Rule 注入
├─ Memory / 项目记忆
├─ Trace / 日志 / 可观测性
├─ Hook / 确定性校验
├─ 权限控制
├─ 人工审批
├─ Fallback
└─ 回滚与审计

一句话：模型负责生成可能的行动，Harness 负责限制行动范围、记录执行过程、判断结果是否合格。

7.11.3 Skill：Agent 的可复用任务能力包

Skill 是把某类任务的操作流程、领域知识、模板、脚本、参考资料和校验规则封装成可复用能力包。它不是一次性的 Prompt，也不是单个工具 API。

my-skill/
├─ SKILL.md          # 入口说明：什么时候触发、如何执行
├─ references/       # 参考资料、规范、模板说明
├─ scripts/          # 高确定性处理脚本
├─ assets/           # 模板、样例文件、图表素材
└─ evals/            # 触发测试、输出测试、回归测试

产品经理要特别关注 Skill 的 description：它决定 Agent 什么时候会触发这个 Skill。描述过宽会误触发，描述过窄会漏触发。

7.11.4 Instruction / Manifest：项目级长期规则

AGENTS.md、CLAUDE.md、GEMINI.md、.github/copilot-instructions.md、Cursor Rules 等文件属于 Agent Instruction / Manifest。它们的作用是为 Agent 提供长期上下文，例如项目结构、构建命令、测试命令、代码风格、安全要求、交付标准。

边界判断：

对象	更适合放什么
Prompt	当前一次任务的目标、输入、输出要求
Instruction / Manifest	项目长期规则、架构、约束、测试命令
Skill	某类可复用任务的执行流程、模板、校验规则
Tool / MCP	Agent 可以调用的外部动作能力
Hook	工具调用前后、提交前后、停止前后的确定性校验

7.11.5 Hook：确定性控制点

Hook 是 Agent 生命周期中的确定性脚本或控制点，适合做“必须执行”的事情，例如：

工具调用前检查危险命令。
工具调用后检查输出格式。
修改文件后自动运行测试。
输出前做 Schema 校验。
停止前生成执行摘要。
检测 API Key、密钥、隐私数据泄露。

核心原则：能用确定性脚本完成的校验，不要交给模型自由发挥；Skill 负责指导，Hook 负责强制。

7.11.6 Subagent：复杂任务的上下文隔离

Subagent 是为专门任务启动的子代理，常用于调研、代码审查、测试、文档分析、方案评估等任务。它的价值是隔离上下文、并行处理、减少主 Agent 的上下文污染。

产品判断：

适合使用 Subagent	不适合使用 Subagent
可并行调研、可独立验证的子任务	强依赖全局上下文的一体化决策
大型代码库分析、文档审查、测试生成	简单问答、单工具调用、固定流程
多方案比较、错误定位、评审复核	高风险动作直接执行

7.11.7 Skill / Tool / MCP / Hook / Harness 的关系

用户任务
→ Prompt 描述本次目标
→ Instruction / Manifest 提供项目长期规则
→ Agent 判断任务复杂度
→ Skill 提供可复用任务流程
→ Tool / MCP 提供外部动作能力
→ Hook 在关键节点做确定性校验
→ Harness 管理上下文、状态、权限、日志、回滚
→ Eval / Governance 判断结果是否可接受

一句话区分：

Skill 教 Agent 怎么做一类事；Tool 给 Agent 一个动作；MCP 标准化连接工具和数据；Hook 强制关键节点校验；Harness 把这些组织成可控运行环境。

7.8 v1.3 进阶：Multi-Agent 协同模式

面对企业级复杂长流程，单体大模型容易遭遇“指令迷失”。多智能体协作（Multi-Agent）通过角色拆分与上下文隔离解决此问题。

7.8.1 典型 Multi-Agent 架构

Supervisor (主管-下属) 模式：一个高级 LLM 扮演 Router，拆解任务给多个垂直子 Agent，最后汇总。适合明确分工。
Swarm / Peer-to-Peer 模式：多个 Agent 在虚拟环境中基于握手协议交互。适合头脑风暴或红蓝对抗。

7.8.2 状态机图与图工作流

引入 LangGraph 等图架构概念。产品经理不仅要画流程图，更要画状态流转图，明确 State Variables 和 Edges。