#工具与 Agent

没有工具时，提示词必须描述 整件工作怎么用语言完成。有工具时，模型多了一条路： 选工具 → 看结果 → 再想。提示词的工作变成：目标、边界、何时用哪把工具、工具失败怎么办——而不是在散文里伪造一套函数调用 JSON（那是 API / SDK 的协议）。

本站把「循环」写在不同容器里，合同相同：

flowchart TD
  P[系统合同：目标与政策] --> M[模型]
  S[工具 schema：名字/参数/何时用] --> M
  U[用户任务] --> M
  M -->|tool call| T[执行]
  T -->|结果当数据| M
  M --> R[对用户的最终答复]

#提示词里该写什么

要写：

• 任务成功标准（「测试通过再结束」）
• 工具选择政策（「实时数据必须搜，不要用训练记忆」；「算术走计算器」）
• 禁止项（「不要提交密钥」；「不要 DROP TABLE」）
• 工具失败时的行为（「报错原文摘要 + 问人」，不要假装成功）
• 最终给人看的格式（短 diff 说明、或结构化摘要）

不要写：

• 手工复述厂商已经注入的参数 JSON
• 「用 XML 伪造一次 function call」来绕过官方 tool 通道
• 把整本 API 手册贴进 system（用 MCP resource 或检索，见 结构）

工具的 description 和参数 schema 是第二份提示词。写清楚「这个工具做什么 / 不做什么」，比在 system 里再抄一遍更有效。含糊的 search(query) 会让模型拿它当万能锤。

# 弱
search: 搜索。

# 强
search_docs: 在本仓库 docs/ 里按关键词检索 Markdown。
用于「教程里怎么写的」类问题。不要用来查实时网页或私有工单。
返回最多 5 条片段；没有命中时返回空列表，不要编造路径。

弱描述逼你在 system 里补一篇「务必正确使用 search」。强描述让模型在选工具那一步就看见边界。MCP 的 tool description、LangChain 的 docstring、Dify 的工具说明，都走这一栏。

#一段可复用的 Agent 政策

你是本仓库的编程助手。先读相关文件再改。
- 需要事实或网页时再搜索；不要编造库的不存在的 API。
- 改代码后跑仓库里已有的测试；失败则修，不要删测试来「变绿」。
- 密钥、`.env`、生产凭证：不要打印、不要写入文档。
- 工具报错时：说明命令与退出码，提出最小下一步，等待确认。
- 最终用几条子弹说明改了什么、怎么验证；不要贴完整文件。

这就是 Cursor 规则、LangChain system_prompt、Dify Agent 提示词该长成的样子。用户消息只给 这一次的任务（「给 parse_order 加超时」），不要每次把政策重贴一遍。

#和聊天提示的差别

人机审批（写文件、发邮件、付钱）是产品能力，也是提示词约束：「高风险动作先概述再等批准」。细节见各产品课，本课只要求你 在合同里写上这一条。

#下一步

• 评估 — Agent 更要回归，不能只看一次演示
• 实战案例 — 仓库级指令
• MCP 简介 · LangChain 工具 · Cursor Agent