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

原创于 2025-10-25 11:18:00 发布 · 939 阅读

CC 4.0 BY-SA版权

文章标签：

#人工智能 #1024程序员节 #embedding #性能优化 #LLM #github

随着人工智能技术的飞速发展，AI Agent 在处理复杂任务方面的能力日益增强。然而，要充分发挥其潜力，优化是不可或缺的一环。本文将综合分析多篇前沿文章，提炼出 AI Agent 中行之有效的优化手段，涵盖Prompt 工程、上下文工程、工具设计、控制循环与架构以及评估与适应等方面，旨在为构建更高效、更稳定的智能体提供指导。

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

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

1.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]。

1.2 LLM 搜索优于 RAG 搜索

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

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

1.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]。

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

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

2.1 KV-cache 命中率优化

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

• 保持 Prompt 前缀稳定：LLM 的自回归特性意味着即使是单个 token 的差异也会使缓存失效。避免在系统 Prompt 开头包含精确到秒的时间戳等易变信息 [1]。
• 上下文追加模式：避免修改历史动作或观察结果，确保序列化过程的确定性，以维持缓存的有效性 [1]。
• 明确标记缓存断点：对于不支持自动增量前缀缓存的模型或推理框架，需要手动插入缓存断点，并确保断点包含系统 Prompt 的末尾 [1]。

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

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

• 文件系统作为外部化记忆：将文件系统视为无限大小、持久化的外部记忆，允许模型按需读写文件，将其作为结构化的外部化记忆使用 [1]。
• 可恢复的压缩策略：在缩短上下文长度时，采用可恢复的压缩策略，例如仅保留网页 URL 而非完整内容，或保留文档路径而非完整文档内容，从而在不永久丢失信息的情况下减少上下文 [1]。

2.3 注意力机制操纵

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

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

2.4 上下文检索与 Agentic 搜索

Agentic 搜索强调 Agent 自主地检索和加载上下文，而非预先处理所有相关数据 [4]：

• “即时”上下文（“just in time”）策略：Agent 维护轻量级标识符（如文件路径、存储的查询、网页链接等），并使用工具在运行时动态加载数据到上下文中。例如，Claude Code 使用此方法对大型数据库进行复杂数据分析，模型可以编写有针对性的查询、存储结果，并利用 Bash 命令（如 head 和 tail）分析大量数据，而无需将完整数据对象加载到上下文中 [4]。
• 元数据利用：引用（如文件路径）的元数据提供了有效细化行为的机制。文件系统中的文件夹层级、命名约定和时间戳等都提供了重要的信号，帮助 Agent 理解何时以及如何利用信息 [4]。
• 渐进式信息披露：允许 Agent 通过探索逐步发现相关上下文。每次交互都会产生上下文，为下一个决策提供信息。Agent 可以逐层构建理解，只在工作记忆中保留必要的信息，并利用笔记策略进行额外持久化 [4]。
• 混合策略：在某些情况下，最有效的 Agent 可能会采用混合策略，预先检索部分数据以提高速度，并根据需要自主探索。例如，Claude Code 预先将 CLAUDE.md 文件直接放入上下文中，同时允许通过 glob 和 grep 等原语即时导航环境和检索文件 [4]。

2.5 长周期任务的上下文工程

对于如大型代码库迁移或综合研究项目等需要跨越数十分钟甚至数小时连续工作的长周期任务 (long-horizon tasks)，Agent 必须在超出模型上下文窗口限制的情况下保持连贯性。仅仅等待更大的上下文窗口可能并非长久之计，因为所有尺寸的上下文窗口都可能受到信息污染和相关性问题的困扰。因此，直接解决这些限制的专门技术至关重要 [4]。

与撰写prompt这一离散任务不同，上下文工程是迭代性的，每当决定向模型传递什么内容时，都会进行筛选阶段。

2.5.1 上下文压缩 (Compaction)

上下文压缩是在对话接近上下文窗口限制时，通过对内容进行总结，并用该总结重新启动一个新上下文窗口的做法。这是提高长期连贯性的首要手段。其核心在于以高保真度提炼上下文内容，使 Agent 能够以最小的性能衰减继续执行任务 [4]。

• 实现方式：在 Claude Code 中，这一过程通过将消息历史传递给模型以总结和压缩最关键的细节来实现。模型会保留架构决策、未解决的错误和实现细节，同时丢弃冗余的工具输出或消息。随后，Agent 可以带着这个压缩后的上下文以及最近访问的五个文件继续工作，从而在不受上下文窗口限制的情况下保持工作的连续性 [4]。
• 优化的艺术：压缩的难点在于精确选择保留与丢弃的内容。过于激进的压缩可能导致丢失那些重要性在后期才显现的微妙但关键的上下文。因此，在实现压缩系统时，建议在复杂的 Agent 轨迹上仔细调整 Prompt。应从最大化召回率开始，确保压缩 Prompt 捕获到轨迹中的每一条相关信息，然后通过消除多余内容来迭代提高其精确度 [4]。
• 轻量级压缩：一种最安全、最轻量级的压缩形式是工具结果清理。一旦某个工具在消息历史的深处被调用过，Agent 通常不再需要看到其原始结果。清除这些结果可以有效减少上下文占用 [4]。

2.5.2 结构化笔记 (Structured Note-taking)

结构化笔记，或称智能体记忆 (agentic memory)，是一种让 Agent 定期将笔记持久化到上下文窗口之外的内存中的技术。这些笔记可以在后续的某个时间点被重新拉取到上下文中。这种策略以最小的开销提供了持久化记忆 [4]。

• 简单模式：像 Claude Code 创建待办事项列表，或让自定义 Agent 维护一个 NOTES.md 文件一样，这种简单的模式允许 Agent 跟踪复杂任务的进展，保持那些在数十次工具调用中可能丢失的关键上下文和依赖关系 [4]。

2.5.3 子智能体架构 (Sub-agent Architectures)

子智能体架构为克服上下文限制提供了另一种途径。它不是让单个 Agent 试图维护整个项目的状态，而是让专门的子智能体在干净的上下文窗口中处理重点任务。主智能体负责协调一个高层计划，而子智能体则执行深入的技术工作或使用工具查找相关信息。每个子智能体可能会进行广泛的探索，使用数万甚至更多的 token，但最终只返回一个浓缩、精炼的工作摘要（通常为1000-2000个 token）[4]。

• 关注点分离：这种方法实现了清晰的关注点分离——详细的搜索上下文被隔离在子智能体内部，而主导的 Agent 则专注于综合和分析结果。这种模式在处理复杂研究任务时，相比单 Agent 系统显示出显著的性能提升 [4]。

这三种方法各有侧重：上下文压缩适合需要大量来回对话的任务；结构化笔记在具有明确里程碑的迭代开发中表现出色；而子智能体架构则在并行探索能带来巨大收益的复杂研究和分析中大放异彩 [4]。

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

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

3.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” 的回复（如下所示）。
```
enum ResponseFormat {
   DETAILED = "detailed",
   CONCISE = "concise"
}
```
- • 甚至工具的回复结构，如 XML、JSON 或 Markdown 等，都会对评估性能产生影响，不存在一种适用于所有情况的解决方案。最佳回复结构会因任务和智能体的不同而差异巨大。建议根据自身评估情况，选择最合适的回复结构。
• 优化工具回复的 token 效率：减少工具回复的 token 数量，以降低成本并提高处理速度 [2]。
• Prompt Engineering 工具描述和规范：精心设计工具的描述和规范，使其更易于 Agent 理解和使用 [2]。
- • 编写工具描述和规格时，不妨设想一下如何给团队新成员介绍该工具。思考那些可能默认提及的上下文信息，比如专业的查询格式、特定术语的定义、底层资源间的关系等，并将它们清晰呈现出来。要通过清楚描述（并借助严格的数据模型加以规范）预期的输入与输出，避免出现模糊不清的情况。尤其要注意，输入参数的命名务必清晰准确，比如别用 user 这样的参数名，改用 user_id 会更好。
- • 利用数据集评估效果，能更确切地衡量提示工程带来的效果。哪怕只是对工具描述做些细微调整，都可能大幅提升性能。

3.2 动态工具选择与约束

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

• 上下文感知的状态机：“状态机” 可理解为 Agent 的 “工具权限开关系统”，它会预先定义不同 “状态”（比如 “浏览网页”“处理文件”“生成报告” 等任务场景），每个状态对应一套 “允许使用的工具列表”。而 “上下文感知” 则是让状态机能实时判断当前处于哪个场景（比如检测到用户需求是 “查天气”，就判定为 “信息检索状态”），进而自动激活对应状态下的工具权限。通过状态机管理工具可用性，例如通过掩码 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 处理器，就能轻松保证智能体在特定状态下仅从某一组工具中做出选择。

3.3 工具分层

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

• 低、中、高层工具结合：例如，低层工具（Bash、Read、Write）、中层工具（Edit、Grep、Glob）和高层工具（Task、WebFetch）。对于频繁使用的操作，可以封装为单独的工具，同时保留通用命令以处理特殊情况 [3]。
• 详细的工具描述：工具描述应包含详细的 Prompt 和大量示例，系统 Prompt 应包含“何时使用工具”或如何在功能重叠的工具之间进行选择的信息 [3]。

3.4 Agent Skills：构建可组合、可扩展的专业能力

Agent Skills 是 Anthropic 刚发布的一种通过结构化文件和文件夹来构建专业化 Agent 的新方法，它将指令、脚本和资源组织起来，使 Agent 能够动态发现和加载这些能力，从而在特定任务中表现更优 [5]。

一个Skill是一个包含 SKILL.md 文件的目录，该文件包含组织好的指令、脚本和资源文件夹，为智能体提供额外的能力。

• 核心理念：Agent Skills 就像为新员工准备的入职指南，它通过将专业知识打包成可组合的资源，将通用 Agent 转化为满足特定需求的专业 Agent [5]。
• 渐进式披露（progressive disclosure）：一个 Skill 是一个包含 SKILL.md 文件的目录。SKILL.md 必须以 YAML Frontmatter 开头，包含名称和描述等元数据。这些元数据会在 Agent 启动时预加载到系统 Prompt 中，提供第一层级的渐进式披露。如果 Agent 认为该 Skill 与当前任务相关，它会加载完整的 SKILL.md 到上下文中，这是第二层披露。对于更复杂的 Skill，可以捆绑额外的文件（如 reference.md 或 forms.md），Agent 可以根据需要进一步导航和发现这些文件，实现更深层次的渐进式信息披露 [5]。

可以将更多上下文（通过附加文件）整合到技能中，然后根据系统提示由 Claude 触发。

• 代码执行能力：Agent Skills 可以包含代码，供 Agent 根据任务性质作为工具执行。大型语言模型在许多任务中表现出色，但某些操作（如排序列表）更适合传统的代码执行，因为代码能提供更高的效率和确定性。例如，一个 PDF Skill 可以包含一个预先编写的 Python 脚本，用于读取 PDF 并提取所有表单字段，Agent 无需将脚本或 PDF 加载到上下文中即可运行，确保了工作流程的一致性和可重复性 [5]。

技能还可以包含代码，Claude 根据任务性质自行决定这些代码是否作为工具被执行。

• 开发与评估最佳实践：
- • 从评估开始：通过在代表性任务上运行 Agent，识别其能力差距，然后逐步构建 Skill 来弥补这些不足 [5]。
- • 结构化以适应规模：当 SKILL.md 文件变得难以管理时，将其内容拆分为单独的文件。如果某些上下文是互斥的或很少一起使用，分开存放可以减少 token 使用。代码既可以作为可执行工具，也可以作为文档，需要明确 Agent 是直接运行脚本还是将其作为参考加载到上下文中 [5]。
- • 从 Agent 视角思考：监控 Agent 在实际场景中如何使用 Skill，并根据观察结果进行迭代。特别关注 Skill 的名称和描述，因为 Agent 会根据这些信息决定是否触发该 Skill [5]。
- • 与 Claude 迭代：在与 Claude 共同完成任务时，让其捕获成功的路径和常见的错误，并将其转化为 Skill 中可重用的上下文和代码。如果 Agent 在使用 Skill 时偏离轨道，让其自我反思问题所在，这有助于发现 Agent 真正需要的上下文 [5]。

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，从而在现实世界中解决更复杂的挑战。

想入门 AI 大模型却找不到清晰方向？备考大厂 AI 岗还在四处搜集零散资料？

别再浪费时间啦！2025 年 AI 大模型全套学习资料已整理完毕，从学习路线到面试真题，从工具教程到行业报告，一站式覆盖你的所有需求，现在全部免费分享！

👇👇扫码免费领取全部内容👇👇