通用优先、粒度整合与退回专用

为什么默认通用工具优于专用工具？

• 原则: 默认取向是通用工具优于专用工具，除非存在明确的安全、权限或性能理由;
• 例子: 与其提供一个四则运算计算器，不如提供通用的 code_interpreter，在沙盒环境中安装好 sympy、numpy、pandas 等库，让 Agent 通过执行 Python 代码完成任意数学计算;
• 依据: LLM 本身具有强大的思考和代码生成能力，应利用这种能力而不是限制它;
• 效果: 通用工具相当于给 Agent 一个“元能力”——一个 Python 解释器就可以代替数十个特定功能的工具，还能处理预先没有想到的边缘场景;

整合粒度以什么为标准？

• 风险: 粒度过细会使工具数量激增、增加 LLM 的选择负担；粒度过粗又会使单个工具过于复杂;
• 标准: 功能相似性与使用场景的重叠度;
• 例子: extract_pdf_text、extract_docx_content、extract_pptx_content 的共性是从文档中提取文本、输入是文件路径、输出是文本字符串，更好的设计是统一的 read_document 工具，用 file_type 参数区分格式;
• 收益: 降低 LLM 认知负担（只需理解“读取文档就用 read_document”）、使描述更清晰、便于扩展（支持新格式只需增加一个 file_type 选项）;

Skill 在参数传递上为什么更脆弱？

• 机制差异: 模型原生工具用 JSON 规定输入输出格式，便于模型遵循指令、生成合法参数并解析输出，部分推理引擎甚至用限制采样强制遵循工具调用格式;
• Skill 负担: Skill 完全用自然语言描述，模型要生成合法的命令行参数，还要对引号等特殊字符转义，转义规则比 JSON 复杂，且随 Linux、Mac、Windows 等环境不同;
• 结论: Skill 对模型提出了更高要求，在参数复杂的情况下也更容易出错;
• 折中: 在 Skill 中要求 Agent 把复杂的结构化参数以 JSON 等格式写入文件，再在命令行中导入这个文件;

哪些情况应退回专用工具？

• 安全、权限与审计: 生产数据库写操作这类场景需要更精细的权限控制与审计粒度，一个开放的 code_interpreter 做不到;
• 屏蔽平台差异、给出更好反馈: grep 与 find 虽可用 bash 实现，但 Mac、Windows、Linux 语法各不相同，专用工具能给出更清晰的行号反馈并屏蔽平台间参数差异;
• 使用频率极高: 高频操作值得一个专属入口，哪怕它在功能上已被通用工具覆盖;
• 参数结构复杂: 涉及嵌套对象、多字段联合校验、复杂类型约束的操作，结构化 schema 能更好地引导模型正确传参;

形态选择由哪四个维度决定？

维度	取向
安全与权限	需要精细授权、审计留痕或有不可逆风险的操作 → 专用工具；其余优先通用
参数复杂度	嵌套对象、多字段联合校验、复杂类型约束 → 专用 schema；参数简单 → CLI 传参同样可靠
变更频率	频繁变化的能力 → Skill（改一段文本远比改代码再测试部署轻松）；稳定的底层操作 → 专用工具
模型能力	较强模型可用 Skill + 通用执行器表达更多能力、减少工具数量；较弱模型需结构化 schema 引导调用

• 迁移: Agent 在持续进化中为自己沉淀新能力时，同样要在这四个维度上取舍;

代码编排工具调用与一次一调用的区别是什么？

• 传统方式: 一次调用一个工具，把每个中间结果都搬进上下文;
• 类比: 就像每做完一步都要写一封邮件汇报给领导，领导读完后再回信告诉你下一步做什么——这些来回的“邮件”就是 token 消耗;
• 代码编排: 领导一次性写好完整的操作手册，照着做即可，只在全部完成后汇报最终结果;
• 机制: LLM 一次性生成一段脚本，中间变量留在代码的执行环境中，只有最终结果才返回 LLM；通用执行器使这种串联成为可能;

代码编排能省多少 token？

• 例子: 抓取多个网页再批量提取字段时，页面全文只存在于执行环境的变量中，返回上下文的只有汇总后的结构化结果，避免整页内容反复进出上下文;
• 量级: token 消耗可降低约两个数量级;
• 定位: 这种“让代码来编排工具调用”的模式，属于第五章展开的“代码作为通用 Agent 元能力”范式;