AI Agent 性能优化：核心策略与实战技巧

type

status

date

slug

summary

1. 上下文工程：精细化管理智能体的“记忆”

上下文是 AI Agent 进行决策和行动的基础，对其进行高效管理是优化的核心。上下文工程超越了传统的 Prompt 工程，它关注在 LLM 推理过程中如何策划和维护最佳的 token 集合，以持续实现预期结果 [4]。

1.1 KV-cache 命中率优化

KV-cache（Key-Value Cache）的有效利用对提高 LLM 的运行效率至关重要。优化策略包括：

保持 Prompt 前缀稳定：LLM 的自回归特性意味着即使是单个 token 的差异也会使缓存失效。避免在系统 Prompt 开头包含精确到秒的时间戳等易变信息 [1]。

上下文追加模式：避免修改历史动作或观察结果，确保序列化过程的确定性，以维持缓存的有效性 [1]。

明确标记缓存断点：对于不支持自动增量前缀缓存的模型或推理框架，需要手动插入缓存断点，并确保断点包含系统 Prompt 的末尾 [1]。

1.2 上下文长度管理与外部化记忆

现代 LLM 拥有巨大的上下文窗口，但过长的上下文仍可能导致性能下降和成本增加。上下文腐烂（Context Rot）现象表明，随着上下文长度的增加，模型回忆信息的能力会降低 [4]。因此，有效的上下文管理至关重要：

文件系统作为外部化记忆：将文件系统视为无限大小、持久化的外部记忆，允许模型按需读写文件，将其作为结构化的外部化记忆使用 [1]。

可恢复的压缩策略：在缩短上下文长度时，采用可恢复的压缩策略，例如仅保留网页 URL 而非完整内容，或保留文档路径而非完整文档内容，从而在不永久丢失信息的情况下减少上下文 [1]。

1.3 注意力机制操纵

Manus 通过持续重写待办事项列表，把目标复述到上下文末尾。这样能让全局计划处于模型当前关注范围内，避免出现 “中途迷失” 的问题，减少目标不一致的状况。实际上，这是借助自然语言将自身关注点引向任务目标，而无需对架构进行特殊改动。

动态重写待办事项列表：通过不断更新和重写待办事项列表（todo list），将全局计划推入模型的近期注意力范围，减少目标偏差 [1, 3]。

<ins/>

2. 工具设计与管理：为智能体打造高效“武器库”

工具是 AI Agent 与环境交互的关键接口。工具的设计质量直接影响 Agent 的效能 [2]。

2.1 工具设计原则

选择合适的工具：审慎决定哪些工具需要实现，哪些可以省略 [2]。

建议针对特定的高价值工作流程，精心打造一些适用的工具，使其与评估任务相匹配，再以此为基础逐步拓展。就通讯录场景而言，可以考虑实现 search_contacts 或 message_contact 工具，而非 list_contacts 工具。
工具可以整合各类功能，在内部处理多个可能离散的操作（或 API 调用）。例如，工具可以利用相关元数据丰富回复内容，或者通过一次工具调用完成频繁串联的多步骤任务。
一些示例：

相较于分别实现 list_users、list_events 和 create_event 工具，不妨考虑实现一个 schedule_event 工具，它既能查找可用时间，又能安排活动。
与其实现 read_logs 工具，不如实现 search_logs 工具，该工具仅返回相关日志行及部分周边上下文。
不要分别实现 get_customer_by_id、list_transactions 和 list_notes 工具，而是实现一个 get_customer_context 工具，它能一次性整合客户所有近期相关信息。

要确保每个构建的工具都有明确且独特的用途。工具应让智能体像人类在拥有相同底层资源时那样，对任务进行细分并解决，同时减少因中间输出而消耗的上下文。
工具太多或其功能重叠，可能会干扰智能体采用高效策略。因此，认真且有针对性地规划要构建（或不构建）的工具，会带来显著成效。

工具命名空间：为工具定义清晰的功能边界，避免混淆 [2]。

通过设置命名空间（把相关工具归到相同前缀下），有助于在众多工具间明确界限，MCP 客户端有时会默认这么做。比如，按照服务（像 asana_search、jira_search）和资源（例如 asana_projects_search、asana_users_search）对工具进行命名空间划分，能帮助智能体在合适的时机选择合适的工具。
选择基于前缀还是后缀的命名空间方式，会对工具使用评估产生不可忽视的影响。而且不同的 LLM 受影响的情况各异，所以建议根据自身评估结果来选择命名方案。
智能体可能会出现调用工具错误、用错参数调用正确工具、调用工具数量不足，或者错误处理工具回复等问题。实现工具时有针对性地设置它们的名称体现任务的自然区分，这样既能减少加载到智能体上下文中的工具数量和描述信息，还能把智能体计算的工作从上下文转移到工具调用本身，从而降低智能体犯错的整体风险。

返回有意义的上下文：工具的输出应向 Agent 提供简洁且有意义的上下文信息 [2]。

在实现工具时，要注意只向智能体返回关键信息。应更注重上下文的相关性，而非追求灵活性，同时避免使用底层技术标识符（比如 uuid、256px_image_url、mime_type 等）。像 name、image_url 和 file_type 这类字段，更有助于直接引导智能体开展后续行动并做出响应。
相较于晦涩的标识符，智能体处理自然语言命名、术语或标识符时，往往更加得心应手。仅需将随意的字母数字 UUID 转换为语义更清晰、更易解读的表述（甚至只是采用从 0 开始编号的 ID 方案），就能减少幻觉现象，显著提升 Claude 在检索任务中的精准度。
在某些情形下，若只是为了触发后续工具调用（例如 search_user (name=’jane’) → send_message (id=12345) ），智能体可能既需要与自然语言输出交互，也需要与技术标识符输出交互的灵活性。可以在工具中设置一个简单的 response_format 枚举参数，让智能体能够选择工具返回 “concise” 还是 “detailed” 的响应（如下所示）。

甚至工具的回复结构，如 XML、JSON 或 Markdown 等，都会对评估性能产生影响，不存在一种适用于所有情况的解决方案。最佳回复结构会因任务和智能体的不同而差异巨大。建议根据自身评估情况，选择最合适的回复结构。

优化工具回复的 token 效率：减少工具回复的 token 数量，以降低成本并提高处理速度 [2]。

Prompt Engineering 工具描述和规范：精心设计工具的描述和规范，使其更易于 Agent 理解和使用 [2]。

编写工具描述和规格时，不妨设想一下如何给团队新成员介绍该工具。思考那些可能默认提及的上下文信息，比如专业的查询格式、特定术语的定义、底层资源间的关系等，并将它们清晰呈现出来。要通过清楚描述（并借助严格的数据模型加以规范）预期的输入与输出，避免出现模糊不清的情况。尤其要注意，输入参数的命名务必清晰准确，比如别用 user 这样的参数名，改用 user_id 会更好。
利用数据集评估效果，能更确切地衡量提示工程带来的效果。哪怕只是对工具描述做些细微调整，都可能大幅提升性能。

<ins/>

2.2 动态工具选择与约束

避免在迭代过程中动态添加或移除工具，因为这会影响 KV-cache 并可能导致模型混淆 [1]。更优的策略是：

上下文感知的状态机：通过状态机管理工具可用性，例如通过掩码 token logits 来约束动作空间，从而在不修改工具定义的情况下限制 Agent 的选择 [1]。

一致的动作名称前缀：设计具有一致前缀的动作名称（例如，所有浏览器工具以 browser_ 开头），以便于在特定状态下对工具进行分组约束 [1]。

在实际应用中，大多数模型供应商和推理框架都支持某种形式的响应预填充（response prefill）功能，借助该功能，无需修改工具定义就能限制动作空间。函数调用一般有三种模式（这里以 NousResearch 的 Hermes 格式为例）：

自动（Auto）：模型可自行决定是否调用函数。具体通过仅预填充回复前缀来实现：<|im_start|>assistant

必需（Required）：模型必须调用函数，但具体调用选择不受约束。通过预填充到工具调用令牌来实现：<|im_start|>assistant<tool_call>

指定（Specified）：模型必须从特定的函数子集中选择调用。通过预填充到函数名开头来实现：<|im_start|>assistant<tool_call>{"name": “browser_

基于此，可以通过直接屏蔽 token logits 来限制动作选择。Manus 还特意将动作名称设计成具有统一前缀，例如所有与浏览器相关的工具均以 browser_ 开头，命令行工具则以 shell_ 开头。这样一来，无需借助有状态的 logits 处理器，就能轻松保证智能体在特定状态下仅从某一组工具中做出选择。

2.3 工具分层

结合使用不同抽象层次的工具，可以提高 Agent 的灵活性和效率 [3]：

低、中、高层工具结合：例如，低层工具（Bash、Read、Write）、中层工具（Edit、Grep、Glob）和高层工具（Task、WebFetch）。对于频繁使用的操作，可以封装为单独的工具，同时保留通用命令以处理特殊情况 [3]。

详细的工具描述：工具描述应包含详细的 Prompt 和大量示例，系统 Prompt 应包含“何时使用工具”或如何在功能重叠的工具之间进行选择的信息 [3]。

<ins/>

3. Prompt 工程：塑造智能体的“思维模式”

Prompt 工程是引导 LLM 行为的关键技术，尤其是在构建复杂 Agent 时。

3.1 系统 Prompt 优化

清晰简洁的语言：系统 Prompt 应该非常清晰，使用简单、直接的语言，以“恰当的高度”呈现思想，既要足够具体以有效指导行为，又要足够灵活以提供强大的启发式方法 [4]。

*在光谱的一端，我们看到脆弱的 if-else 硬编码提示，在另一端，我们看到过于笼统或错误地假设共享上下文的提示。*

结构化 Prompt：建议将 Prompt 组织成不同的部分（如 <background_information>、<instructions>、## Tool guidance、## Output description 等），并使用 XML 标签或 Markdown 标题来划分这些部分 [4]。

尽量用最少的话术列出对模型的所有预期：最佳做法是先用可用的最佳模型测试初版包含所有预期的最少话术的 prompt，以查看其在任务上的表现，然后根据初始测试中发现的失效模式添加清晰的指令和示例来改进性能。

详细的启发式规则和示例：Prompt 中应包含详细的启发式规则、示例和重要提醒，例如使用 <good-example> 和 <bad-example> 来明确区分可取和不可取的行为路径 [3]。

团队通常会往提示中塞满各种边缘情况，试图阐明 LLM 在特定任务中应遵循的每一种可能规则。不推荐这样做。相反，建议努力策划一组多样化、规范化的示例，这些示例能够有效地展现代理的预期行为。对于 LLM 来说，示例就是胜“千言万语”的“图片”（the “pictures” worth a thousand words）。

用户上下文和偏好管理：使用 claude.md 或类似文件来传递无法从代码库推断的上下文和严格偏好，例如强制 LLM 跳过某些文件夹或使用特定库 [3]。

3.2 LLM 搜索优于 RAG 搜索

在某些场景下，直接利用 LLM 的代码理解能力进行搜索可能优于传统的 RAG（Retrieval-Augmented Generation）方法 [3]：

利用 LLM 理解代码：Claude Code 通过复杂的 ripgrep、jq 和 find 命令搜索代码库，利用 LLM 对代码的深刻理解，使用复杂的正则表达式查找相关代码块，甚至使用小型模型读取整个文件。这种方法避免了 RAG 引入的新的（隐藏的）故障模式 [3]。

3.3 可控性与行为引导

有效引导 AI Agent 的行为，使其符合预期，是 Prompt 工程的重要组成部分 [3]：

明确的语气和风格控制：在系统 Prompt 中明确定义 Agent 的语气、风格和主动性，并提供具体的指令和示例。这有助于 Agent 在交互中展现出一致且合宜的行为 [3]。

示例：避免不必要的前言或后语，除非用户明确要求；如果无法提供帮助，不要解释原因或可能导致的后果，以免显得说教；除非用户明确要求，否则避免使用表情符号 [3]。

强调式指令：使用“IMPORTANT”、“VERY IMPORTANT”、“NEVER”和“ALWAYS”等强调词来引导模型避免特定行为或强制执行关键规则。这在模型尚未完全可控时尤为重要 [3]。

示例：IMPORTANT: DO NOT ADD ***ANY*** COMMENTS unless asked；VERY IMPORTANT: You MUST avoid using search commands like find and grep. Instead use Grep, Glob, or Task to search. [3]。

编写清晰的决策算法：识别 LLM 需要执行的最重要任务，并为其编写清晰的算法。通过角色扮演 LLM 并遍历示例，明确所有决策点，并以流程图的形式进行结构化。这有助于 LLM 遵循指令，避免“一锅粥”式的 Do's and Don'ts 列表，从而减少冲突和提高可维护性 [3]。

Claude Code 的系统 Prompt 中，“Task Management”、“Doing Tasks”和“Tool Usage Policy”等部分清晰地阐述了要遵循的算法，并包含大量启发式规则和各种场景示例 [3]。

<ins/>

4. 控制循环与架构：构建稳定高效的智能体骨架

Agent 的控制循环和底层架构设计对其稳定性和效率至关重要。

4.1 保持一个主循环

简化架构以提高可调试性：优先考虑可调试性，而不是复杂的、多代理的系统。例如，Claude Code 采用一个主线程，通过周期性地使用不同类型的 Prompt 来总结 git 历史、合并消息历史或生成 UX 元素。对于分层任务，它通过生成一个不能再生成子代理的子代理来处理，其结果作为“工具响应”添加到主消息历史中 [3]。

4.2 使用小型模型

成本效益与效率：对于读取大文件、解析网页、处理 git 历史和总结长对话等操作，超过 50% 的重要 LLM 调用都使用 claude-3-5-haiku 等小型模型。小型模型成本更低，可以大量使用，从而提高整体效率 [3]。

5. 评估与适应：持续改进智能体性能

Agent 的持续改进离不开有效的评估和适应机制。

5.1 原型构建与综合评估

快速原型与本地测试：快速构建工具原型并在本地测试，尤其是在使用 Claude Code 编写工具时，提供详细的文档（如 LLM-friendly 的 llms.txt 文件） [2]。

生成评估任务：创建大量基于真实世界用例的评估任务，避免过于简单或肤浅的“沙盒”环境。强评估任务可能需要多次工具调用 [2]。

系统 Prompt 指导：在评估 Agent 的系统 Prompt 中，指导 Agent 不仅输出结构化的响应块，还要输出推理和反馈块（在工具调用和响应块之前），以触发思维链（CoT）行为 [2]。

避免过度指定或过拟合：允许 Agent 有多种解决任务的有效路径，避免过度指定或过拟合策略 [2]。

5.2 错误恢复与适应

智能体难免会犯错，这并非缺陷，而是客观存在的情况。语言模型可能出现幻觉，环境可能返回错误信息，外部工具也可能运行异常，各种意外的边缘情况随时都可能出现。在多步骤任务中，失败并非个别现象，而是任务循环中的常见环节。

根据经验，改进智能体行为的一个极为有效的方法，实则相当简单：把错误的步骤保留在上下文当中。当模型看到某个动作失败，以及随之产生的观察结果或堆栈跟踪信息时，会不自觉地更新其内部认知。这会使模型在后续决策中，减少选择类似动作的可能性，从而降低重复犯错的概率。实际上，错误恢复能力是衡量智能体是否具备真正智能行为的重要指标之一。

不隐藏错误：将失败的动作和观察结果（如堆栈跟踪）保留在上下文中，让模型通过观察错误隐式更新其内部信念，从而减少重复犯错的可能性。错误恢复是衡量真正 Agentic 行为的关键指标 [1]。

5.3 多样性与泛化

少样本提示是改善大语言模型（LLM）输出的常用方法，但在智能体系统里，它可能会以不易察觉的方式带来负面影响。

语言模型很擅长模仿，会依照上下文中的行为模式进行输出。要是上下文里有大量相似的动作-观察（action-observation）组合，模型就容易遵循这种模式。

在那些需要重复做决策或行动的任务中，这种情况很可能引发问题。比如说，用 Manus 去批量审阅 20 份简历时，智能体经常会形成一种惯性，只是因为在上下文中看到了类似行为，就重复相似的操作。这就可能导致偏离目标、过度泛化，甚至产生幻觉。

要解决这个问题，关键在于增加多样性。Manus 通过在动作和观察中引入少量的结构化变动，像是采用不同的序列化模板、变换措辞，或者在顺序与格式上制造些微干扰。这种适度的随机性能够打破固有模式，调整模型关注的重点。也就是说，别让少样本提示把自己限制住，上下文越单一，智能体就越容易出问题。

避免过度模仿：在 few-shot prompting 中，避免过度模仿导致模型陷入重复模式。通过引入结构化的多样性（如不同的序列化模板、替代措辞、格式噪声）来打破模式，提高模型的泛化能力和鲁棒性 [1]。

结论

AI Agent 的优化是一个多维度、系统性的工程。从精细的上下文管理到高效的工具设计，从巧妙的 Prompt 工程到稳定的控制循环，再到持续的评估与适应，每一个环节都对 Agent 的最终性能产生深远影响。通过采纳这些优化手段，我们可以构建出更智能、更鲁棒、更具适应性的 AI Agent，从而在现实世界中解决更复杂的挑战。

<ins/>

参考文献

Context Engineering for AI Agents: Lessons from Building Manus

Writing effective tools for AI agents—using AI agents \ Anthropic

Minusx | What makes Claude Code so damn good (and how to recreate that magic in your agent)!?

Effective context engineering for AI agents \ Anthropic