AI 智能体是一个带着工具在循环中运行的语言模型：它决定做什么，调用工具，读取结果，并持续到任务完成。为智能体写提示词，与为单次回答写提示词不同。你不再是在写一个问题，而是在为一个将在没有你的情况下做出许多决定的对象写运行指令。
工作流还是智能体
首先决定你是否真的需要智能体。
| AI 工作流 | AI 智能体 | |
|---|---|---|
| 谁决定步骤 | 你的代码 | 模型 |
| 可预测性 | 高 | 较低 |
| 成本与延迟 | 较低，事先已知 | 较高，且不固定 |
| 适合 | 有已知流程的任务 | 路径取决于发现结果的任务 |
| 调试 | 逐步进行 | 阅读完整轨迹 |
如果你能画出流程图，就用提示词链构建工作流。当步骤的数量和顺序无法事先知道时，例如排查一个缺陷或研究一个问题，再使用智能体。
智能体提示词的组成部分
智能体的行为来自它读取的四样东西：系统提示词、工具定义、任务，以及返回的结果。每一样都需要用心编写。
1. 系统提示词
涵盖六件事。
角色与目标。 智能体的用途，用两句话说明。
运行规则。 如何工作：在改动任何东西之前先调查，倾向于小步前进，验证结果。
边界。 它不得做什么，以及什么需要批准。
如何处理问题。 工具错误、信息缺失、含糊不清。
何时停止。 表示任务已完成的条件，以及努力的上限。
如何汇报。 最终回答包含什么。
You are a coding agent working in the user's repository.
## How to work
- Read the relevant files before proposing a change.
- Make the smallest change that satisfies the task.
- After editing, run the tests that cover the change.
## Boundaries
- Do not modify files outside the repository.
- Do not delete files or run destructive commands without asking.
- Do not change public interfaces unless the task says so.
## When things go wrong
- If a command fails, read the error and try a different approach once.
If it fails again, stop and report what you tried.
- If the task is ambiguous, ask one question before starting.
## When to stop
- Stop when the acceptance criteria are met and the tests pass.
## Final report
- What changed and why, files touched, how it was verified, and
anything left undone.
当规则背后的原因并不明显时，要解释清楚。智能体会遇到你没有列出的情形，带原因的规则比单纯的禁令更容易举一反三。
2. 工具定义
模型通过阅读工具的名称和描述来选择工具。定义含糊是智能体用错工具的最常见原因。
- 按工具的功能命名： 用
search_orders，而不是query2。 - 描述每个工具何时使用，何时不该使用。
- 说明返回什么， 包括格式和限制。
- 让参数毫无歧义： 类型、格式、允许的取值、一个示例。
- 避免功能重叠的工具。 如果两个工具都能完成任务，模型的选择就会不一致。
- 返回可操作的错误： “日期必须是 YYYY-MM-DD”，而不是“输入无效”。
少量描述良好的工具，胜过大量相似的工具。Model Context Protocol对工具如何被描述并提供给智能体做了标准化。
3. 任务提示词
给智能体一份规格说明，而不是一句话。它的自主性越高，起始简报就越重要。
## Objective
Add rate limiting to the public API.
## Requirements
- 100 requests per minute per API key.
- Return 429 with a Retry-After header when exceeded.
## Constraints
- Existing clients must keep working: no changes to response schemas.
## Acceptance criteria
- New tests cover the limit and the 429 response.
- The existing test suite passes.
验收标准让智能体知道自己何时完成，也让你有办法检查。PromptFlowEngine VS Code 扩展会把一行任务转换成这种结构，并附上相关文件。
4. 上下文管理
智能体读取的一切都会留在它的上下文中，并在每一步被重新读取。如果放任不管，上下文就会被过时的工具输出填满，成本上升，质量下降。
- 返回精简的工具结果。 只返回需要的字段，而不是整个载荷。
- 总结或丢弃旧的结果， 一旦用过。
- 对于长任务，把持久的笔记保存在上下文之外， 放在智能体可以读取和更新的文件里。
- 委派。 把一项自成一体的子任务交给上下文全新的子智能体，只取回它的结论。
参阅 token 优化。
为子智能体编写提示词
当一个智能体向另一个智能体交代任务时，简报就是接收方所知道的全部。一份好的委派提示词应说明：
- 目标及其重要性。
- 已经知道的内容，避免重复工作。
- 想要的确切输出及其格式。
- 边界：该动什么，不该动什么。
写出含糊简报的协调者智能体，得到的也是含糊的成果。这里自动检查会有帮助：智能体可以在委派之前，把简报草稿交给 PromptFlowEngine MCP 工具，找出缺失的目标或输出格式。
智能体的安全
智能体会采取行动，所以错误和攻击都会带来后果。
- 最小权限。 每个工具只拥有能用的最窄权限。默认只读。
- 不可逆操作需要批准。 删除、发送、付款、部署。
- 把工具结果视为不可信。 网页或文件中可能含有针对智能体的指令。参阅提示词注入。
- 限制。 最大步数、最大花费和超时。
- 让密钥远离上下文。 把凭据直接交给工具。参阅个人信息与密钥检测。
- 记录每一次工具调用， 以便审查一次运行。
常见的失败模式
| 症状 | 可能的原因 | 修正 |
|---|---|---|
| 在同一个动作上循环 | 没有停止规则或步数上限 | 两者都加上 |
| 过早宣布成功 | 没有验收标准 | 定义验收标准；要求验证 |
| 使用了错误的工具 | 描述重叠或含糊 | 重写工具描述 |
| 做的远多于要求 | 没有说明范围 | 明确说明边界 |
| 忘记之前的指令 | 上下文过载 | 精简结果、做总结、使用笔记 |
| 遵循了文件中发现的文本 | 没有标记不可信内容 | 标记为数据；限制工具 |
评估智能体
对结果打分，而不是对路径：测试是否通过，是否更新了正确的记录，答案是否正确。然后审阅轨迹，查找浪费的步骤和有风险的操作。保留一组结果已知为良好的任务，并在提示词、工具或模型变化时重新运行。参阅提示词测试与评估。
关于这一切背后的推理循环，参阅 ReAct 提示词。