📝 提示词工程对比

策略 1: 极简截断 (SWE-agent, Smolagents)

最简单的方式——当上下文超过限制时，截断最早的消息。

messages = messages[-max_messages:]  # 保留最近 N 条

优点: 实现简单 缺点: 丢失重要上下文

策略 2: 摘要压缩 (OpenHands, AutoGPT)

当上下文接近限制时，用另一个 LLM 调用生成摘要，替换旧消息。

# OpenHands Condenser
if token_count(messages) > threshold:
    summary = llm.summarize(old_messages)
    messages = [summary_message] + recent_messages

优点: 保留关键信息 缺点: 额外 LLM 调用、摘要可能丢失细节

策略 3: 检查点回溯 (LangGraph)

保存每一步的 State 快照，可以回退到任意检查点重新执行。

# LangGraph Checkpointing
state_snapshot = checkpoint.save(current_state)
# 可以回退:
state = checkpoint.load(snapshot_id)

优点: 完整的可追溯性 缺点: 存储开销大

策略 4: 记忆检索 (Agent Zero, AutoGPT)

将过去的经验存入向量数据库，按需检索相关记忆注入上下文。

# Agent Zero 的核心创新
relevant_memories = memory.search(current_task)
context = f"Past solutions:\n{relevant_memories}\n\nCurrent task: {task}"

优点: 自我进化、越用越好 缺点: 检索质量依赖 embedding、可能引入噪音

策略 5: 仓库地图 (Aider)

用 tree-sitter 解析代码库，生成精简的函数/类签名列表作为上下文，而非完整文件。

# Aider RepoMap
repo_map = tree_sitter_analyze(repo)  # 生成函数签名列表
# 注入到系统提示词: "Here are the relevant functions:\n{repo_map}"

优点: 极高信息密度、代码库全局视野 缺点: 仅适用于代码、实现复杂

三大范式

模板系统分类

Browser Use 的 XML 分段架构（最佳实践）

Browser Use 的系统 prompt 是目前分析中最精细的结构化 prompt，使用 XML 标签将 ~300 行指令分为 10+ 个逻辑段：

<intro>              — 核心能力声明
<language_settings>  — 语言偏好
<input>              — 每步输入结构说明
<agent_history>     — 历史记录格式
<user_request>      — 用户任务（最高优先级）
<browser_state>     — DOM 树交互元素格式
<browser_vision>    — 截图使用指南
<browser_rules>     — 浏览器操作规则（20+ 条）
<file_system>       — 文件系统使用指南
<planning>          — 计划系统（plan_update/current_plan_item）
<task_completion>   — 完成验证（含 pre_done_verification 检查清单）
<action_rules>      — 多动作组合规则
<efficiency_guidelines> — 动作分类与组合建议
<reasoning_rules>   — 推理模式要求
<examples>          — 输出格式示例
<error_recovery>    — 错误恢复策略

关键设计: <pre_done_verification> 要求在调用 done 前执行 6 步检查清单（重新读任务→逐项验证→确认动作完成→验证数据来源→检查阻塞错误→任何不确定则 success=false），这是防止 LLM 过早声称成功的精妙设计。

Smolagents 的三模态 YAML 模板

Smolagents 提供三种 Agent 变体，每种有完整的 YAML 模板集：

共享子系统: 三种 Agent 共享 planning 子系统（initial_plan + update_plan_pre/post_messages）和 managed_agent 子系统（task 模板 + report 模板）。

Facts Survey 模式: planning 的 initial_plan 要求先做 "事实调查"（已知事实/需查找/需推导），再制定计划。这是一种结构化 Chain-of-Thought，强制 Agent 在行动前先盘点信息。

Agent Zero 的插件化 Prompt 架构

Agent Zero 不使用单一 system prompt，而是通过插件系统动态组合：

plugins/
  _text_editor/prompts/     — 12 个 prompt 文件
    agent.system.tool.text_editor.md  — 工具描述（read/write/patch）
    fw.text_editor.patch_ok.md       — 框架反馈：patch 成功
    fw.text_editor.patch_error.md    — 框架反馈：patch 失败
    fw.text_editor.write_ok.md       — 框架反馈：写入成功
    ...
  _code_execution/prompts/  — 11 个 prompt 文件
    agent.system.tool.code_exe.md    — 代码执行工具描述
    fw.code.running.md              — 框架反馈：运行中
    fw.code.pause_dialog.md         — 框架反馈：暂停对话框
    ...
  _browser/prompts/         — 浏览器交互 prompt
  _memory/prompts/          — 记忆系统 prompt
  _a0_connector/prompts/    — 远程 Agent 连接 prompt

关键设计: 框架反馈（fw.*.md）是 Agent Zero 的独特创新——不是由 LLM 决定反馈内容，而是框架根据执行结果自动注入对应的反馈 prompt，确保 LLM 收到准确的系统状态信息。

Google ADK: Processor Pipeline 模式

最干净的中间件架构。12 个有序 Processor，每个单一职责：

Request Pipeline:
  basic → auth → confirmation → instructions → identity →
  compaction → contents → context_cache → interactions →
  nl_planning → code_execution → output_schema

Instructions Processor 三层体系:
  global_instruction (已废弃) → static_instruction (可缓存) →
  instruction (动态, {var} 模板)

  if static_instruction 存在:
    static → system_instruction (可 Gemini Context Cache)
    dynamic → user content (每轮更新)
  else:
    all → system_instruction

亮点: static_instruction + instruction 分离专为 Gemini Context Caching 优化，是所有框架中唯一考虑缓存成本的设计。

Agno: 17 步瀑布式管线

最全面也最不透明的提示词构建：

get_system_message() 200+ 行:
  1.  description        → 简单文本
  2.  role               →  标签包裹
  3.  instructions       →  标签或列表
  4.  additional_info    → markdown/time/location/name
  5.  tool_instructions  → 工具使用指引
  6.  resolve_in_context → {var} → string.Template.safe_substitute
  7.  expected_output    →  标签
  8.  additional_context → 自定义上下文
  9.  skills             → Skill 提示词片段
  10. memories           → 
      + agentic_memory   → update_user_memory 工具指引
  11. cultural_knowledge →  文化知识
      + agentic_culture  → create_or_update_cultural_knowledge 工具指引
  12. session_summary   → 
  13. learnings         → 学习结果
  14. search_knowledge  → RAG 搜索指令
  15. model system msg  → 模型特定提示
  16. JSON output       → 结构化输出指引
  17. session_state     →  完整状态

风险: 17 个注入点可能导致 system prompt 膨胀到数千 token。Cultural Knowledge 是创新但尚未见大规模验证。

PydanticAI: 装饰器注册 + Graph 执行

最 Pythonic 但扩展性有限的设计：

# 静态 prompt
agent = Agent('openai:gpt-4', system_prompt='You are helpful.')

# 动态 prompt（带类型安全依赖注入）
@agent.system_prompt
async def get_prompt(ctx: RunContext[MyDeps]) -> str:
    return f"Language: {ctx.deps.language}"

# 每轮刷新 prompt
@agent.system_prompt(dynamic=True)
async def get_time(ctx: RunContext[MyDeps]) -> str:
    return f"Time: {datetime.now()}"

# resolve_system_prompts() 内部:
#   1. 添加静态字符串 → SystemPromptPart
#   2. 执行 runners → 检查 _takes_ctx / _is_async
#   3. dynamic=True → SystemPromptPart(dynamic_ref=func.__qualname__)
#   4. 后续轮次通过 dynamic_ref 匹配替换

对比: 无法像 ADK 插入自定义 processor，无法像 Agno 配置大量上下文注入点。但 dynamic_ref 标记是优雅的刷新机制——精确替换而非全量重建。

Aider: ChatChunks 分块缓存架构

专为 Anthropic Prompt Cache 优化的消息分块设计：

class ChatChunks:
    system: list          # 系统提示词（最高缓存优先级）
    examples: list        # Few-shot 示例
    done: list            # 已完成对话轮次
    repo: list            # RepoMap 代码地图
    readonly_files: list  # 只读文件内容
    chat_files: list      # 可编辑文件内容
    cur: list             # 当前轮次
    reminder: list        # 格式提醒（有空间才注入）

关键设计: 1) reminder 只在 token 预算充足时注入，避免挤占核心内容；2) 分块顺序对齐 Anthropic 缓存断点——system/examples 优先缓存，中间块增量更新；3) 后台 cache warming 线程定期发送最小请求保持缓存存活。

对比: 所有框架中唯一考虑 API 缓存成本 的提示词设计（Google ADK 考虑的是 Gemini Context Cache，但不如 Aider 这么精细到消息块级别）。

LangGraph: Command 统一控制流原语

LangGraph 不约束提示词（“bring your own prompts”），但它的 Command 原语控制了 Agent 的所有输出路由：

Command(
    update={"key": "value"},     # 更新 State
    goto="node_name",            # 路由到指定节点
    graph=Command.PARENT,        # 上报父图
    resume="user_input",         # 从中断恢复
)

# 节点返回 Command 即可同时更新状态 + 控制流程
def review_node(state) -> Command:
    if state["approved"]:
        return Command(goto="execute")
    return Command(goto="revise", update={"feedback": "请修改"})

关键设计: Command 统一了 4 种控制流——状态更新、节点路由、中断恢复、子图上报——为单一对象。与 Aider 的 SEARCH/REPLACE 文本输出和 PydanticAI 的 result_type 类型输出不同，LangGraph 的输出格式就是控制流本身。