什么是 AI Agent 系统#
- Agent 系统是一种能够独立完成任务的系统，与传统软件不同，它可以在用户授权下高度独立地执行工作流。
- Agent 系统的核心在于利用 LLM 进行工作流管理和决策，并能够根据需要动态选择工具与外部系统交互。
何时应该构建 AI Agent 系统#
- Agent 系统适用于那些传统自动化方法难以处理的复杂、多步骤任务，例如需要复杂决策、难以维护规则或依赖非结构化数据的场景。
- 例如，在支付欺诈分析中，Agent 系统能够像经验丰富的调查员一样评估上下文并识别可疑活动。
AI Agent 设计基础#
- Agent 系统由三个核心组件构成：模型（LLM）、工具（外部 API）和指令（明确的行为指南）。
- 模型选择应基于任务复杂性、延迟和成本的权衡。
- 工具应标准化定义，以便在代理系统之间灵活使用。
- 指令需要清晰明确，以减少歧义并提高决策质量。
编排模式#
- 单 Agent 系统：一个模型配备适当工具和指令，以循环方式执行工作流。
- 多 Agent 系统：将工作流分布在多个协调的 Agent 之间，分为 “管理型”（一个中心 Agent 协调多个专业 Agent）和 “去中心化型”（多个 Agent 平等地相互移交任务）。
防护栏#
- 防护栏是确保 Agent 系统安全运行的关键，用于管理数据隐私风险和声誉风险。
- 防护栏可以包括相关性分类器、安全性分类器、PII 过滤器、内容审核和工具安全评估等。
- 防护栏的设置应基于实际风险，并随着新漏洞的发现而不断调整。
实施建议#
- 从单 Agent 系统开始，逐步扩展到多 Agent 系统。
- 使用灵活的提示模板来简化维护和评估。
- 在 Agent 系统中实施人类干预机制，以应对高风险或失败的情况。
Agent 提示词实践#
Persistence (持久性)#
告诉模型这是个多轮人物，需要一直工作到问题解决，不是回答一句就完事
You are an agent - please keep going until the user’s query is completely resolved, before ending your turn and yielding back to the user. Only terminate your turn when you are sure that the problem is solved.
->
你是一个智能助手 - 请持续工作直到用户的问题完全解决，再结束你的回合。只有当你确定问题已解决才停止。
Tool-calling (工具调用)#
鼓励模型在不确定时主动使用工具查询，而不是瞎猜
If you are not sure about file content or codebase structure pertaining to the user’s request, use your tools to read files and gather the relevant information: do NOT guess or make up an answer.
->
如果你不确定文件内容或代码结构，请使用工具查询相关信息：绝对不要猜测或编造答案。
Planning (规划)#
引导模型在每次调用工具前先规划，调用后再反思。这能让模型 “把思考过程说出来”，提高解决问题的能力 (推理模型不依赖)
You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully.
->
你必须在每次函数调用前进行详细规划，并在调用后对结果进行深入反思。不要只依靠函数调用解决整个问题，
工具调用的正确姿势#
- 强烈建议用 API 的 tools 字段：别再手动在提示词里塞工具描述了！官方测试表明，通过 API 传递工具定义，可以减少错误，让模型表现更好（SWE-bench 提升 2%）
- 起个好名字，写清楚用途：工具名称和描述要清晰明了，参数也一样，这能帮模型正确使用工具。
- 复杂工具用法放例子里：如果工具比较复杂，最好在系统提示中专门开个 "# Example" 部分，保持描述简洁。
推荐的指令编写流程#
- 先给出整体要求：用 "指令" 或 "回复规则" 标题列出基本要求
- 分点说明细节：针对具体行为用子标题详细说明
- 明确步骤顺序：如需按特定流程操作，用有序列表明确标出
- 调试与优化：
- 检查指令间是否矛盾
- 提供清晰的例子演示你想要的结果
- 谨慎使用全大写、感叹号等强调手段，可能导致模型过度关注这些点
常见的坑和解决办法#
- 必须 XX陷阱：比如强制要求 “每次回复前必须调用工具”，可能导致模型乱调用。解决方法：补充说明 “信息不足时先询问用户”。
- 照搬示例问题：模型可能直接复制你给的例子。解决方法：明确说明 “参考但不限于这些例子，根据情况灵活调整 "。
- 话太多问题：有时模型会输出太多解释或不必要的格式。解决方法：在指令中明确要求简洁和具体格式”。
上下文处理#
- 能力边界：虽然基础能力强，但在需要从海量信息中检索很多信息，或者进行需要全局信息的复杂推理时，性能可能会下降。
- 最佳实践：把指令同时放在上下文的开头和结尾各重复一次
- 可以明确指示模型是只能用你提供的信息回答，还是可以结合自身知识库
思维链#
引导模型像人一样 “思考”，把复杂问题分解成小步骤解决简单的思维链指令 （推理模型不依赖）：
...First, think carefully step by step about what documents are needed to answer the query. Then, print out the TITLE and ID of each document. Then, format the IDs into a list.
->
...首先，仔细逐步思考需要哪些文档来回答查询。然后，列出每个文档的标题和ID。最后，将ID格式化为列表。
进阶 CoT：如果发现模型思考过程有偏差，可以通过更具体的指令来规范它的思考策略。比如，指南里给了一个例子，要求模型先做查询分析 (Query Analysis)，再做上下文分析 (Context Analysis)，最后综合 (Synthesis)。
推荐的 Prompt 结构模板#
# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps (e.g., Chain of Thought instructions)
# Output Format
# Examples
## Example 1
# Context (if any)
# Final instructions and prompt to think step by step (e.g., the CoT starter)
->
# 角色和目标
# 指令
## 更详细指令的子类别
# 思考步骤（如思考链指令）
# 输出格式
# 示例
## 示例1
# 上下文（如有）
# 最终指令和逐步思考提示
分隔符选择#
- 首选 Markdown：标题、列表、代码块等，清晰直观
- XML 也不错：适合精确包裹内容，便于嵌套
- JSON 相对繁琐：结构强但在提示词中可能需要转义
- 长文档场景：XML (
<doc id=1 title=”...”>...</doc>) 和类表格 (ID: 1 | TITLE: ... | CONTENT: ...) 格式效果好，JSON 表现较差