Agent工具与行动

Tools = "可以做什么"（能力清单），Action = "实际做了什么"（具体动作）。

二者是 Agent 与真实世界的接触点——Tools 解决"能不能做"，Action 解决"该不该做、要不要确认"。PM 在 Agent PRD 里最容易出错的就是 Tools 设计和 Action 风险分级，因此它们要放在一起讲。

Tools — Agent 的工具箱

Tools 是 Agent 能调用的外部能力——搜索、计算、读写文件、调 API、操作浏览器、执行代码。LLM 本身只能"生成文本"，要做这些事必须"装上工具"。

工具调用流程

用户提问 → LLM 决定用哪个 tool → 调用 tool → 拿到结果 → 继续推理

底层机制是 Function Calling（2023.6 OpenAI 首发），现已是所有主流大模型的标配能力。详见 Function Calling与MCP。

常见 Agent 工具清单（5 类）

Agent 形态	工具清单	每个工具具体做什么（举例）
调研类 Agent	browser_search / browser_open / read_pdf / write_file	返回搜索结果列表 / 打开网页提取正文 / 解析 PDF 内容 / 把笔记存到文件
编程类 Agent	read_file / edit_file / run_command / search_code	读取代码 / 替换代码片段 / 跑测试 / 全局搜索符号
浏览器类 Agent	click / type / scroll / screenshot	点击登录按钮 / 输入文字 / 向下滚动 / 截图观察当前页面
办公类 Agent	create_doc / edit_excel / send_email / schedule_meeting	创建 Word 文档 / 修改单元格 / 发邮件 / 创建日历邀请
客服类 Agent	search_kb / lookup_order / create_ticket / refund	检索知识库 / 查订单状态 / 创建工单 / 发起退款

Tools 设计的 3 个常见错误

错误 1：1 个 tool 解决 1 个用户目标

反例：

tool:
  name="manage_user",
  description="管理用户，可以创建、删除、修改、查询用户信息"

LLM 会迷失：要"创建"还是"查询"？怎么传参数？

正例：

search_user(name="张三")              → 查询用户
create_user(name="张三", role="PM")   → 创建用户
update_user(id=123, role="总监")      → 修改用户
delete_user(id=123)                   → 删除用户

原则：一个 tool 只做一件事，名字直接说清楚做什么。

错误 2：Tool Description 是说明书，不是简介

反例：

search(query) — 搜索东西

正例：

search(query: str, max_results: int = 10) — 用关键词在互联网上搜索信息。
  - query: 搜索关键词，建议用中英文各搜一次以获得更全面的结果
  - max_results: 返回结果数量，默认 10 条
  - 返回：标题、URL、摘要
  - 注意：只返回搜索结果列表，不会打开网页。如需阅读网页内容，请使
        用 browser_open

原则：Description 是写给 LLM 看的说明书——要说清楚做什么、怎么传参、返回什么、什么时候用什么时候不用、和其他 tool 的边界。

错误 3：Tool 数量过多（甜蜜点是 10-15 个）

Agent 产品	实际 Tool 数量	经验
Kimi K2 探索	~10 个核心 Tool	搜索、网页浏览、文件生成、代码执行等
Claude Code	~12 个 Tool	读、写、搜索、执行命令、联网搜索等
ChatGPT Plugin（已废弃）	单次对话最多 3 个	太少，能力严重受限，已废弃

原则：Tool 太少 → 能力受限；Tool 太多 → LLM 选择困难、Context 浪费、错调率上升。10-15 个是当前主流产品的甜蜜点。

如果工具实在太多（30+），考虑用 Code Execution with MCP 范式（详见 Function Calling与MCP）——只暴露一个 execute_code 工具，LLM 写代码按需导入 MCP Server，Token 节省 95%+。

Tool Use vs RPA

维度	RPA	Agent Tool Use
执行逻辑	固定脚本——程序员写死每一步	LLM 动态决定——根据情境选择工具和参数
适应变化	页面改版就可能崩溃	能理解变化、调整操作
开发成本	每个流程单独开发、单独维护	通用 LLM + 工具描述，一次配置多场景
适用范围	高频重复的标准流程	需要判断力的非标场景
类比	流水线机械臂——按固定程序做固定动作，精确但僵硬	实习生的双手——不一定每次动作完全一样，但能根据情况灵活应对

简单判断：流程不变 + 高频 → RPA；流程多变 + 需要判断 → Agent Tool Use。

Action — Agent 真正执行的那一刻

Tools 是"能力清单"（可以做什么），Action 是"实际做了什么"（具体动作）。

PM 在 Action 上要做的关键决策：

什么 Action 需要用户确认？
什么可以自动执行？
Action 失败了怎么办？
怎么恢复？

Action 风险分级

风险等级	类型	例子	处理方式
低风险	读取类	搜索、读文件、查询数据	全自动执行，不打扰用户
中风险	生成类	写文档、起草邮件、生成代码	自动执行，但生成完给用户 review
高风险	不可逆类	发邮件、下订单、删数据、退款	必须用户确认才能执行

PRD 必备：Action 分级表

写 Agent PRD 时，必须为每个 Action 标注三件事：

Action 名称	风险等级	是否需要用户确认	失败时如何降级
搜索网页	低	否	重试 1 次后跳过
起草邮件	中	写完后让用户 review	退回让用户手动写
发送邮件	高	必须用户点"确认"	不允许失败，必须用户介入

Action 是 Agent 跟真实世界的接触点，也是 PM 需要重点把控"安全边界"的地方。

Manus 的 Action 设计

回看 Agent五要素技术定义中的 Manus 案例——它的所有写文件、调用 API、执行代码都跑在沙箱环境里，本质上是把"实际产生影响的 Action"圈在了一个受控空间里。这是另一种风险控制思路：用沙箱代替逐项确认，让中风险动作可以自动执行而不会扩散风险。