基础概念

什么是上下文？

简单说就是：发送给大模型的所有信息被称为上下文。包括但不仅限于 system/user 提示词、约束规则、示例、工具说明、历史对话、摘要、长期记忆、检索结果、数据库/代码执行返回、用户权限与业务状态等。

什么是上下文工程？

上下文工程（Context Engineering）是围绕“在有限上下文窗口内，让模型看到最有用的信息、并按最有效的方式呈现”所做的系统化设计与实现。它把一次模型调用当成一个信息管道问题：哪些信息该进入上下文、以什么形式进入、放在什么位置、如何随对话演进而更新，最终目标是提升输出的正确性、稳定性、可控性与成本效率。

优化方向的一些总结

• Context Retrieving（选择性取回）：需要时从外部存储（笔记/记忆/数据源）检索并注入当前步骤必需的信息，而不是把所有东西都塞进来。比如使用 RAG 或者 glob 和 grep 做文件检索。
• Context Offloading（卸载）：把大块数据、工具输出、权限/状态等放到文件/DB/缓存中，提示中只保留可索引的引用（路径、URL、主键）
• Context Reduction（减少）：通过压缩（Compaction）和总结（Summarization）降低 token 与噪声，但避免不可逆地丢失关键细节
• Context Isolation（隔离）：通过 Multi-Agent 把指令、知识、工具原始日志、可执行结论分区；
• Context Caching（缓存）：保持提示前缀稳定、上下文 append-only、序列化确定性（例如 JSON key 顺序固定），提升命中率并降低 TTFT/成本

其他细节：

• 沙箱工具可以固定放 “/usr/bin”下面，可以通过简单紧凑的描述告诉模型工具列表，让模型通过 -h 查看具体使用方式。
• 优先考虑基于行的格式，因为这允许模型使用 grep 或按行范围读取，存储数据的格式，推荐用纯文本。markdown 会导致模型输出太多 bullet points。
• Summarization，不要用自由形式的 prompt 让 AI 生成所有内容，而是定义一种 schema，就像一个表单，有很多字段让 AI 填写。
• Multi-Agent 通信：在 Sub Agent 的角度，有一个特殊的工具叫 submit result。我们使用 constrained decoding 来确保 sub agent 提交回主 Agent 的内容符合主 Agent 定义的 schema。
• 提供尽量少、职责清晰的的原子工具。比如读写文件、执行 shell 命令、搜索文件和互联网，以及一些浏览器操作。我们认为这些原子函数有非常清晰的边界，它们可以组合成更复杂的工作流。
• 对添加更多 sub agents 保持谨慎，SubAgent as tool。
• 把 MCP 工具从“直接工具调用”变成“代码 API 调用”。把一些 Response 很大的 mcp 接口放到代码里面出去，过滤出自己要的信息再吐给大模型。
• Tool Search Tool（工具搜索/按需加载），不再把所有工具定义预先加载到模型上下文，而是先只给一个“搜索工具”的入口；模型需要能力时再去“搜”相关工具，把少量命中的工具定义加载进上下文。
• Programmatic Tool Calling（程序化工具调用），当任务需要多步编排（循环、条件、分页抓取、批量处理、去重合并等）时，用自然语言每步推理会慢且占上下文；程序化调用允许在一个“代码执行环境”里组织工具调用流程，把编排逻辑放进代码，而不是反复把中间状态写进对话。
• Tool Use Examples（工具使用示例），给模型提供“高质量、可泛化的调用范式示例”，让模型学到团队/API 的真实约定与最佳实践，从而提升选参正确率与鲁棒性。
• 将较长的工具响应转换为文件
• 在摘要过程中引用对话历史
• 高效地仅加载所需的 MCP 工具, Cursor 这个优化点跟上面 cluade 的 Tool Search Tool 类似
• 将所有集成终端会话视为文件

业界的一些最佳实践

Context Engineering for Agents（langchain）

• 文章链接：Context Engineering for Agents

为什么需要上下文工程

• 长上下文会带来多类失效模式（文中引用 Drew Breunig 的分类），典型包括：
  • Context Poisoning：错误/幻觉进入上下文后被反复放大
  • Context Distraction：无关信息过多干扰决策
  • Context Confusion：多余信息影响模型判断
  • Context Clash：上下文内部信息不一致造成冲突
• 智能体任务往往“长程、跨多轮”，如果不管理，上下文会被截断或充斥噪声，影响任务完成率。

上下文的主要来源（文中归类）

• 指令类：提示词、记忆、few-shot 示例、工具说明等
• 知识类：事实、长期/短期记忆等
• 工具类：工具调用返回的反馈与中间结果

四类常见策略（文章主线）

• Write（写入上下文到窗口外）：把关键信息保存到上下文之外，避免被截断并可复用
  • 例：Scratchpad（任务内笔记/工作草稿）把计划与中间结论写到外部存储
  • 例：Memories（跨会话记忆）通过反思/总结生成可长期复用的记忆
• Select（选择性取回）：需要时从外部存储（笔记/记忆/数据源）检索并注入当前步骤必需的信息，而不是把所有东西都塞进来
• Compress（压缩）：把冗长的对话、工具日志、证据链等总结/抽取成更短但信息密度更高的表示，以控制 token 与噪声
• Isolate（隔离）：把不同类型/不同来源的上下文分区或隔离，减少互相污染与冲突（例如把工具原始日志与可执行结论分开）

总结

• 文章提出“上下文工程（Context Engineering）”是构建智能体（Agent）时最关键的工程工作之一。在每一步行动前，把“刚好需要的信息”放进有限的上下文窗口（把上下文窗口类比为 LLM 的“RAM”）。
• 智能体会在“模型推理 ↔ 工具调用”之间反复迭代，工具反馈会不断累积，导致上下文变长、成本变高、性能变差，因此需要系统化的上下文管理策略。
• 上下文工程要服务于“下一步动作”的决策质量：既要信息充分，又要避免冗余、冲突与幻觉进入工作记忆。
• 文中指出 LangGraph 的设计目标之一是更好地支持这些策略（写入、选择、压缩、隔离），以适配长程、多工具、多轮次的智能体运行。

Context Engineering for AI Agents: Lessons from Building Manus

• 文章链接：Context Engineering for AI Agents: Lessons from Building Manus

为什么选择“上下文工程”而不是端到端训练代理模型

作者对比了过去微调模型的时代（如 BERT）和现在大模型的“上下文学习”范式：以前每次任务迭代都要训练和评估，反馈极慢，不适合快速迭代的产品；而现在可以通过设计上下文和提示在几小时内改进系统。Manus 团队因此选择把精力放在“怎么构造上下文”上，而不是自己从零训练代理模型。

围绕 KV-Cache 设计：把“缓存命中率”当成一等公民指标

• 在 Agent 里，输入上下文会随“工具调用→观察→追加到上下文”的循环不断增长，但每轮模型输出往往很短，导致“prefill（吃上下文）远多于 decode（出答案）”，文章提到平均输入/输出 token 比可到 100:1。
• 这使 KV-cache 命中率成为生产级 Agent 的关键指标：相同前缀越稳定缓存收益越大，TTFT（首 token 延迟）和推理成本下降越明显；某些服务商缓存 token 与非缓存 token 成本可相差 10 倍。
• 保持提示词前缀稳定：哪怕开头多一个“秒级时间戳”也会让后续缓存失效。
• 上下文“只追加（append-only）”：不要回写/修改历史行动与观察，序列化要确定性（尤其注意 JSON key 顺序等隐性不稳定因素）。
• 必要时显式设置缓存断点：在不支持自动增量前缀缓存的框架/供应商里，手动插入“可缓存边界”，并考虑缓存过期。
• 自托管推理要把前缀缓存打开（如 vLLM 一类框架），并用会话路由（例如 session id）保证同一会话尽量打到同一 worker，提升复用。

工具/能力越多，越要“Mask，不要 Remove”

• Agent 能力扩展会带来工具数量爆炸（尤其在可插拔工具生态下），工具越多模型越容易选错动作或走低效路径。
• 作者主张更偏“屏蔽/收敛可见动作空间（mask）”，而不是频繁增删工具定义（remove）。直觉上，这既能让模型在当前任务更聚焦，也能让提示前缀更稳定，从而不牺牲缓存命中率与系统一致性。

把文件系统当作“真正的上下文和外部记忆”

即便有 128K 甚至更大的上下文窗口，真实代理任务仍常常超出上下文限制，而且长上下文会变慢、变贵，效果还可能下降。Manus 的思路是：

• 把文件系统视为“无限上下文”和外部记忆：代理学会按需读写文件，而不是把所有细节塞进提示里。
• 上下文里的“压缩”要可恢复，例如只保留 URL 或文件路径，把具体内容移出上下文，需要时再从网页或文件重读，而不是做不可逆摘要。
  作者还展望，如果状态空间模型（SSM）结合这种外部文件记忆，可能会开启新一类高效代理。

通过“不断复述目标”来操纵注意力（todo.md 的用法）

• Manus 在较复杂任务中，会自动生成并反复更新一个 todo.md，不断勾选已完成任务。
• 这不只是 UX，而是刻意的“注意力操控”：通过在循环中持续重写待办清单，把任务的全局计划和关键目标推到上下文尾部，让它处于模型的“近期注意力”内，从而减少在长任务中“跑偏”或忘记最初目标。

保留错误，而不是把错误“洗掉”

代理在多步任务中出错是常态：模型会幻觉、工具会报错、环境会出各种异常。许多系统会选择隐藏错误、重置状态，只把“看起来干净”的历史喂给模型。

• 把失败的动作、错误栈、异常信息都保留在上下文中。
• 模型看到这些失败证据后，会调整内部先验，减少重复同样错误的概率。作者认为“错误恢复能力”是衡量真正代理行为的重要指标，但在学术与基准中经常被忽视。

不要被少样本提示（few-shot）“锁死行为模式”

在代理场景，如果上下文中堆满相似的历史示例，模型会强烈模仿这种模式，哪怕它已不再最优。例如在审简历等重复任务中，模型可能陷入“节奏”，一遍遍重复同类动作，导致偏置或幻觉。

Manus 的应对方式是引入“受控多样性”：

• 在动作/观察的序列化格式、措辞、顺序等方面加入少量结构化噪声，保持行为模式的多样性，打破单一模式。

总结：上下文工程是代理系统的核心工程学

文章最后强调：模型会持续变强、变快、变便宜，但这无法取代对“记忆、环境和反馈”的良好设计。一个代理的真正行为和能力，很大程度由你如何塑造上下文来决定——包括缓存策略、工具组织方式、外部记忆用法、错误保留策略、以及如何在长任务中维持目标和多样性。

Context Engineering for AI Agents with LangChain and Manus

• 视频链接：Context Engineering for AI Agents with LangChain and Manus

主要探讨了 AI 智能体中的上下文工程，基于构建 Manus 项目的实践经验，强调了上下文管理的重要性、常见陷阱以及优化策略。总结将按照文档的逻辑结构展开，内容力求丰富和详细。

为什么需要上下文工程？

文档首先解释了上下文工程的必要性，指出两个常见陷阱：

• 第一个陷阱：产品团队常倾向于训练自定义模型，但模型迭代会限制产品迭代速度。在达到产品市场契合（PMF）之前，应避免构建专用模型，而是优先优化上下文。
• 第二个陷阱：在项目稳定后，团队可能想通过强化学习（RL）进行微调，但这会重建基础模型公司已有的能力，反而增加复杂度。

上下文工程被定义为应用与模型之间的清晰边界，它通过优化上下文来释放模型潜力，而不改变模型本身。

上下文减少（Context Reduction）

上下文减少旨在压缩冗余信息，避免模型过载。文档区分了两种方法：

• 压缩（Compaction）：直接精简工具调用和结果的原始文本，例如移除重复内容，但保留关键数据。
• 总结（Summarization）：将多个文件或操作摘要为高层描述，如将文件创建过程概括为“用户已创建3个文件”，从而减少上下文长度。

过度减少可能导致信息丢失，因此需谨慎平衡。实践中，Manus 倾向于卸载（offload）而非减少，以降低风险。

上下文隔离（Context Isolation）

在多智能体设置中，上下文同步会带来高昂开销。文档借鉴了并发编程的智慧：

• “通过通信共享内存” vs “通过共享内存通信”：前者更高效，它让智能体通过消息传递协作，而非直接共享上下文，从而减少冲突和依赖。例如，主智能体可以协调子智能体，通过通信传递结果，而非让所有智能体访问同一上下文。

隔离不当可能导致协调问题，如多智能体之间的冲突。

上下文卸载（Context Offloading）

卸载指的是将工作记忆（如工具调用结果）保存到外部存储（如文件），以减轻模型负担。文档重点介绍了分层动作空间（Hierarchical Action Space），包含三个层次：

• Level 1: 函数调用（Function Calling）：标准模式，但缓存易被更改破坏，且函数过多会导致上下文混乱。
• Level 2: 沙盒工具（Sandbox Utilities）：让模型在VM沙盒中调用CLI工具（如shell命令），易于扩展且不污染上下文，适合处理大输出（如写入文件）。
• Level 3: 包和API（Packages & APIs）：模型编写Python脚本来调用预授权API，适用于数据密集型任务（如获取天气数据），保持上下文清洁。

所有层次都通过标准函数调用接口实现，确保设计正交且缓存友好。

整合所有方法

文档强调，各种上下文工程方法相互促进：

• 卸载（Offload）和检索（Retrieve）结合，为减少（Reduction）提供基础。
• 可靠的检索使隔离（Isolation）更可行，从而降低减少的频率。
• 整个过程需在缓存优化下进行，以提升效率。

避免上下文过度工程

最后，文档警告不要过度工程化：更多上下文不等于更高智能，简化往往优于扩展。Manus 的经验表明，最大的收益来自移除而非添加内容。关键原则是“构建更少，理解更多”（Build less, understand more），保持边界清晰，让模型自由发挥。

Claude Code: Best practices for agentic coding

• 文章链接：Claude Code: Best practices for agentic coding

核心建议：从“环境与上下文”入手优化使用体验

• 用 CLAUDE.md 固化项目经验：在仓库根目录（或合适子目录/父目录/home目录）放置 CLAUDE.md，让工具自动纳入上下文，用于记录高频命令、关键文件、代码风格、测试方式、仓库协作规范、环境配置、已知坑点等。
• 把 CLAUDE.md 当成可迭代的“提示词资产”：不要一次塞很多内容就不管；像调 prompt 一样持续精炼，让它更短、更明确、更可执行。团队也可以把这些改动随代码一起提交，沉淀成共享规范。
• 按需分层放置：在 monorepo 场景下，可以在不同层级目录放多个 CLAUDE.md，让不同子项目自动获得各自的上下文与规则。

权限与安全：把“强能力”变成“可控能力”

• 管理允许的工具/操作清单（allowlist）：默认对可能修改系统的动作更保守，需要授权。你可以通过会话内选择“总是允许”、使用权限管理命令、或编辑配置文件（例如项目内 .claude/settings.json 或全局配置）来定制允许的工具范围。
• 原则：只放行你确信安全、易回滚或已被团队认可的操作，把效率和风险控制平衡好。

推荐的典型工作流

• “Explore → Plan → Code → Commit”：先让 Claude 阅读相关文件/图片/URL，再让它 思考并写计划（用 “think / think hard / ultrathink” 增加推理预算），确认后再写代码、最后自动提交和建 PR，这比直接写代码效果好得多。
• TDD 工作流：“先写测试再写实现”：先让 Claude 写测试并确认失败，再写实现、反复跑测直到通过，最后分别提交测试和代码；可用次级代理检查是否“过拟合测试”。
• UI 迭代工作流：给 Claude 截图或设计稿，让它实现界面、自动截图结果并反复对比迭代，直到接近视觉目标。
• “安全 YOLO 模式”：使用 claude --dangerously-skip-permissions 关闭权限确认，适合在隔离容器中批量修 lint、生成模板等，但需严格限制网络和数据，防止风险。
• 代码库问答：把 Claude 当成熟悉代码库的同事，询问“日志如何实现”“如何新增 API”“某行代码含义”“某实现的边界情况”等，Claude 会主动查找代码和 git 历史，尤其适合新成员入项。
• Git / GitHub 操作：让 Claude 搜索 git 历史、写 commit message、处理复杂 rebase/冲突，以及创建 PR、修 review 评论、修失败构建、批量整理 issue 等，减少记忆命令细节。
• Jupyter 笔记本：请它阅读、生成、清理和美化 notebook 以及可视化输出，方便科研和数据分析展示。

提升交互质量的通用技巧

• 指令要具体：明确要改的文件、要覆盖的场景、要使用/避免的技术，比模糊指令效果好很多。
• 善用图片、文件名、URL：主动提供截图、设计稿、文件路径和链接，让 Claude 能直观理解目标和上下文。
• 主动点名要修改的文件：用 Tab 补全文件/目录名，引导 Claude 精准操作。
• 频繁纠偏：通过让 Claude 先写计划、使用 Escape 中断、双击 Escape 回溯编辑旧提示、让 Claude 撤销修改等方式，尽早纠正方向。
• 用 /clear 管理上下文：长会话中定期清空历史，保持上下文聚焦当前任务。
• 对大型多步任务，用 Markdown 清单/草稿板：让 Claude 先生成待办列表（如所有 lint 错误），再逐项修复并打勾。
• 多种方式传数据：复制粘贴、管道输入（cat foo.txt | claude）、让 Claude 自己用工具拉数据或读文件/URL，组合使用能更高效定位问题。

headless 模式

• 使用 claude -p “” 开启 headless 模式，并配合 --output-format stream-json 便于在 CI、pre-commit、构建脚本中自动调用 Claude。
• 典型用途包括：自动 issue 分析和打标签、充当“智能 linter”给出主观代码评审（命名是否清晰、注释是否过时等）。

多 Claude 协作与并行工作

• 多 Claude 分工：一个 Claude 写代码，另一个审查或写测试，再用第三个综合两者反馈修改，实现类似多工程师协作效果，且各自上下文互不干扰。
• 多工作副本 / worktree：为不同任务创建多个仓库副本或 git worktree，在多个终端/IDE 窗口中让不同 Claude 并行处理相互独立的改动。
• 结合 headless 模式和脚本，实现大规模“扇出”（如批量迁移上千文件）或流水线式处理（Claude 输出 JSON，再由其他命令继续处理）。

Code execution with MCP: Building more efficient agents

• 文章链接：Code execution with MCP: Building more efficient agents

文章讨论了在大规模使用 MCP（Model Context Protocol，模型上下文协议）连接外部工具时，传统“直接工具调用”模式会带来高延迟与高成本的问题，并提出用“代码执行（code execution）+ MCP”的方式，把 MCP 工具以“代码 API”的形态暴露给智能体，从而显著减少上下文占用与中间结果的 token 往返。

背景：MCP 为什么会遇到效率瓶颈

• MCP 是一种把 AI agent 连接到外部系统（工具与数据源）的开放协议，目标是“实现一次集成，获得大量生态工具可用”。
• 随着 MCP 生态扩张（大量 MCP server、工具数量动辄上百上千），agent 往往需要面对两个会线性放大成本的环节：工具定义（definitions）和工具调用的中间结果（intermediate results）。

传统 MCP 客户端的两类典型 token 浪费

• (1) 工具定义挤占上下文
  • 许多 MCP 客户端会把“所有可用工具的定义”一次性加载进模型上下文（包含名称、描述、参数、返回结构等）。
  • 当工具数量上千时，模型在“读到用户问题之前”就要先吞下大量工具 schema，直接造成响应变慢、推理成本变高。
• (2) 中间结果反复经过模型上下文
  • 传统方式通常是：模型发起工具调用 → 工具返回大结果（例如长文档） → 结果被塞进上下文 → 模型再把其中内容复制/改写到下一次工具调用里。
  • 文章用“从 Google Drive 取会议纪要，再写入 Salesforce 记录”的例子说明：同一份大文本可能在上下文里出现多次；两小时会议的转写文本甚至可能带来额外数万 token 处理量。
  • 除了成本，反复“拷贝-粘贴”也会提升出错概率（漏字段、截断、格式变形）。

核心方案：把 MCP 工具从“直接工具调用”变成“代码 API 调用”

• 文章提出的关键转变是：不要让模型在对话里直接进行一轮轮 tool-call，而是让模型“写代码”，在一个可执行的运行环境里通过代码去调用 MCP 工具。
• 直观理解：
  • 以前：模型必须“看见全部工具定义 + 看见每次工具结果全文”，再决定下一步。
  • 现在：模型只需要“写出调用哪些工具、如何处理数据的代码”，大数据在运行环境里被处理，最后只把必要的摘要/结论回传给模型对话。

一种具体落地方式：为 MCP 工具生成“代码文件树”

• 文章给出一个实现思路：把每个 MCP server 的每个工具生成一个对应的代码文件（示例用 TypeScript）：
  • servers/<server-name>/<tool-name>.ts：导出一个函数，内部通过通用的 callMCPTool(...) 发起真实调用
  • servers/<server-name>/index.ts：聚合导出该 server 的工具
• 这样模型在写代码时，就像在调用本地 SDK：
  • 需要哪个工具就 import 哪个文件（天然“按需加载”，不必把所有 schema 塞进上下文）
  • 大的中间结果（长文档、JSON 列表）在执行环境里做解析、筛选、清洗、聚合
  • 只把最终需要写回的少量字段或摘要传回模型上下文/下一步调用

这种模式带来的收益

• 减少上下文占用：不再把“全量工具定义”硬塞给模型；只引入用到的那部分代码接口。
• 减少中间结果 token 往返：大文本/大结构不必在模型上下文里反复出现；在执行环境里处理完再输出精简结果。
• 降低复制型错误：避免模型在多次工具调用之间“手动搬运”大段内容，降低遗漏、截断、错贴的概率。
• 更可工程化：工具以代码形态存在后，更容易做类型约束、复用封装、测试与维护（尤其在工具规模很大时）。

适用场景与边界

• 更适合：
  • 工具数量多（上百/上千）、定义加载成本高
  • 工具返回结果大（长文档、长列表、复杂 JSON），需要多步处理/提取
  • 需要多工具编排，且中间结果不希望反复进入上下文
• 可能的前提/代价：
  • 需要一个可靠的代码执行环境（沙箱、依赖管理、权限与网络策略）
  • 需要把 MCP 工具“产品化”为可调用的代码接口（例如生成文件树、封装通用调用函数）

一句话总结

• 文章的结论是：当 MCP 工具生态变大时，把“工具调用回路”从对话层迁到“代码执行层”，让 agent 通过代码按需加载工具并在运行时处理数据，可以同时解决“工具定义爆上下文”和“中间结果爆 token”两大瓶颈，让大规模工具编排更快、更便宜、更稳。

Introducing advanced tool use on the Claude Developer Platform

• 文章链接：Introducing advanced tool use on the Claude Developer Platform

主要讨论“AI Agent 未来会同时连接成百上千个工具”的现实工程问题：工具越多，越容易把上下文窗口与推理预算消耗在“工具定义”和“中间结果”上，导致还没开始解决用户任务就已接近上下文上限，并且更容易选错工具、传错参数。

Anthropic 给出的方向是：不要把所有工具一次性塞进上下文；要按需发现与加载；并且在合适场景下用“代码”而不是纯自然语言去做工具编排。

核心痛点：大规模工具库带来的上下文与准确率问题

• 上下文开销爆炸：当你接入多个 MCP server（如 GitHub、Slack、Jira、Sentry 等）时，工具 schema/说明本身可能就占用数万到十万级 token；文章举例中，5 个 server 的 58 个工具大约消耗 55K token（还没算对话历史和系统提示）。
• 选错工具与参数：工具数量大、命名相似（例如 notification-send-user vs notification-send-channel）时，模型更容易混淆，导致调用失败或行为偏差。
• 自然语言工具调用的编排成本：每一次“调用—返回—再推理—再调用”都需要完整推理回合；循环、条件分支、数据整形等编排逻辑会产生大量中间文本，把上下文越堆越满。

三项新能力（Advanced Tool Use）

1. Tool Search Tool（工具搜索/按需加载）

• 解决什么：不再把所有工具定义预先加载到模型上下文，而是先只给一个“搜索工具”的入口；模型需要能力时再去“搜”相关工具，把少量命中的工具定义加载进上下文。
• 怎么工作（机制）
  • 你仍然把全部工具定义提供给 API，但可将大部分工具标记为 defer_loading: true（延迟加载）。
  • 初始上下文只包含 Tool Search Tool（以及少量 defer_loading: false 的关键工具）。
  • 模型要做某事（如 GitHub 操作）时先搜索 “github”，系统只把匹配到的少数工具（如 createPullRequest、listIssues）展开给模型。
• 效果（文中数据点）
  • 传统方式：先加载全部工具定义（示例中 ~72K tokens），再加上对话历史/系统提示，总体在“开始工作前”就可能达到 ~77K tokens。
  • Tool Search Tool：初始仅 ~500 tokens + 按需加载少量工具（3–5 个工具约 ~3K tokens），总上下文消耗示例约 ~8.7K tokens，保留了约 95% 的窗口。
  • 内部评测显示在 MCP 场景准确率提升（文中给出 Opus 4 / 4.5 的提升数据），核心原因是“更少无关工具干扰 + 更聚焦的工具集合”。

2. Programmatic Tool Calling（程序化工具调用）

• 解决什么：当任务需要多步编排（循环、条件、分页抓取、批量处理、去重合并等）时，用自然语言每步推理会慢且占上下文；程序化调用允许在一个“代码执行环境”里组织工具调用流程，把编排逻辑放进代码，而不是反复把中间状态写进对话。
• 关键思想
  • 代码适合做 orchestration：循环/分支/数据转换对代码天然友好。
  • 减少推理回合与上下文堆积：中间变量留在运行时环境里，不必每步都写成大量文本返回给模型。
• 文章给的直观例子：类似“Claude for Excel”这种需要对成千上万行数据反复读取/修改的场景，程序化调用可以避免在对话里堆满中间结果。

3. Tool Use Examples（工具使用示例）

• 解决什么：JSON schema 只能表达“参数结构合法”，但很难表达“正确用法模式”：什么时候该填可选参数、哪些参数组合才合理、分页怎么处理、幂等怎么做、错误码如何重试等。
• 关键思想：给模型提供“高质量、可泛化的调用范式示例”，让模型学到团队/API 的真实约定与最佳实践，从而提升选参正确率与鲁棒性。

工程方法论（可迁移的经验）

• 工具越多，越需要“发现式”而非“预加载式”的上下文管理：把“工具全集”留在系统侧，模型侧只保留与当前任务强相关的子集。
• 在推理与执行之间做分工：
  • 推理：决定目标、选择策略、选择哪些工具。
  • 执行：用代码做循环/分支/批处理/数据整形，把过程状态留在执行环境，避免反复写回上下文。
• 靠示例补齐 schema 的表达盲区：用示例把“团队约定”和“成功路径”教给模型，减少“结构正确但语义不对”的失败。

适用场景总结

• 大型企业 Agent：连接 GitHub/Slack/Jira/Drive/内部数据库等大量工具，最容易被工具定义挤爆上下文。
• 重编排任务：需要分页拉取、批量更新、对大量记录做循环处理、或需要多轮条件判断的流程型任务。
• 工具易误用的 API：参数多、可选项多、或存在强约定（如幂等键、分页、速率限制、错误重试策略）的接口。

Improving frontend design through Skills

• 文章链接：Improving frontend design through Skills

问题：为什么 AI 生成的前端容易“撞脸”

• 典型默认风格：Inter 字体、白底紫渐变、几乎无动效、标准化布局。
• 根因是“分布式收敛（distributional convergence）”：模型采样时更倾向于训练数据里“高概率、最安全、最不冒犯”的设计选择，导致输出落在“平均值审美”的中心区域。
• 结果是：品牌辨识度被削弱，AI 生成界面一眼可识别、也更容易被用户忽视或否定。

挑战：可控性强，但上下文成本高

• 好消息：Claude 对提示词很“可控”，只要明确要求“避开 Inter/Roboto”“不要纯色背景”等，效果会立刻提升。
• 难点：真正有效的前端指导涉及多个维度（字体、配色、动效、背景质感等）。如果每次都手写长提示词很麻烦；但如果塞进系统提示词，又会让你在做别的任务（写邮件、调试后端）时也背着前端上下文，造成无谓的上下文开销，甚至影响表现。

核心方案：Skills = 按需加载的“领域提示词/知识包”

• Skill 本质：一个放在指定目录中的文档（常见是 markdown），里面包含指令、约束、领域知识；模型在需要时通过读文件工具动态加载。
• 关键价值：把“前端审美与实现指导”做成可复用资产，在“要做前端”时才加载，而不是永久占用上下文窗口。
• 进一步的工程意义：避免上下文窗口过载导致质量下降，同时让团队把最佳实践沉淀为“组织级知识”。

如何提示才更有效：把审美映射到可实现的代码维度
文章强调：前端设计提示词要像前端工程师思考——用能落到代码的维度去描述审美改进。

• Typography（字体）

  • 明确禁止“无聊/泛用字体”（如 Inter、Roboto、Open Sans、Lato、系统默认）。
  • 给出可选字体方向（如偏代码感、偏社论感、偏技术、偏独特风格等）。
  • 给出组合原则：用高对比的字体搭配、用更极端的字重与字号跃迁、选一个鲜明字体并“用得果断”，并从 Google Fonts 加载。
  • 观察：仅仅把字体要求写清楚，经常会带动模型在其他设计维度上也更用心。

• Themes（主题化审美）

  • 利用模型对“流行主题/风格范式”的理解，用几条要点就能传达整体气质。
  • 示例是 RPG/Fantasy 审美：戏剧化配色、装饰性边框、羊皮纸/皮革质感、史诗光影、中世纪衬线标题等。

• 通用前端审美 Skill（约 400 tokens）

  • 目标：显式点破“你会趋向 generic / AI slop 审美”，要求“做出有角色感、令人惊喜的前端”。
  • 覆盖四大向量：Typography、Color & Theme（用 CSS 变量保持一致性、主色+强对比点缀优于平均配色、从 IDE 主题/文化审美找灵感）、Motion（强调关键时刻的编排式动效，如页面加载的 staggered reveal）、Backgrounds（用渐变/几何图案/氛围层次替代纯色）。
  • 同时列出要避免的默认套路：过度使用的字体族、紫白渐变陈词滥调、可预测布局与组件模式、缺乏场景角色的“饼干模具式设计”。
  • 还有一个很实用的点：即使禁掉一批默认选择，模型也可能收敛到“另一个局部最优”（例如某些新流行字体），因此需要最后再强调“跳出另一个收敛中心、强制多样化”。

效果展示：同样的需求，开了 Skill 就明显更像“真人设计”

• 文章用三类界面做对比：SaaS 落地页、博客布局、管理后台。
• 对比维度集中在：字体辨识度、配色一致性、背景层次、视觉层级、动效的目的性与整体气质。

在 claude.ai 的另一层限制：Artifacts 的“单 HTML 文件”约束

• 文章指出：在 claude.ai 里生成可渲染的前端 Artifact 时，Claude 默认会写成一个 HTML 文件（含 CSS/JS），这会天然限制复杂度与工程化能力。
• 解决：做了一个 web-artifacts-builder skill，引导 Claude 用更现代的工具链做更强的 artifact：
  • 开发时使用多文件与现代技术栈（例如 React、Tailwind CSS、shadcn/ui）。
  • 最后用打包工具把多文件产物 bundle 回“单 HTML”，以满足 artifact 的渲染约束（文章举例使用 Parcel）。
  • Skill 还可以通过脚本帮 Claude 自动化样板工程搭建与打包，从而减少 token 消耗、提高稳定性。
• 示例对比：白板应用、任务管理应用；开启 skill 后，界面更完整、更“产品化”，并且能直接利用成熟组件库能力（表单、布局等）。

结论与可迁移方法论

• 更大的结论是：模型往往“能力在，但默认不显露”；缺少指导时会被分布式收敛遮蔽。
• Skills 的通用套路：
  • 识别默认收敛的套路（convergent defaults）
  • 提供具体可执行的替代方案
  • 把指导写在“合适的抽象高度”（既不死给具体到每个 hex 值，也不空泛到只说“更高级”）
  • 封装成可复用的 Skill，让团队长期受益
• 适用范围不止前端：任何“模型输出偏泛化、缺少领域味道”的场景，都适合用 Skills 机制来做质量与一致性提升。

Dynamic context discovery (Cursor)

• 文章链接：Dynamic context discovery

为什么需要“动态上下文发现”

• 长对话与复杂工程里，静态上下文会越来越臃肿：工具输出（巨大 JSON）、终端日志、MCP 工具描述等都会迅速吃满上下文窗口。
• 常见处理方式是“截断输出”或“压缩总结”，但这会丢关键信息；而上下文一旦混入大量不相关内容，也会降低模型判断与检索能力。
• 动态上下文发现的目标：只在“用得上时”把“那一小段必要信息”引入上下文，并且能在信息缺失时回到来源继续取证。

Cursor 给出的 5 种做法（从“如何把信息变得可按需加载”入手）

把很长的工具响应转成文件

• 问题：第三方工具（shell、MCP 等）可能返回超长结果，直接塞进对话会导致上下文膨胀；截断又可能丢失关键细节。
• 做法：将完整输出落盘成文件，让 Agent 通过“读文件”的方式按需查看；先用类似“tail 看末尾”的方式快速定位是否需要更多信息，再决定继续读取哪一段。
• 价值：既避免一次性吞下全部输出，又保留了“可追溯的完整原文”，需要时能回去继续读，不必依赖有损总结。

在摘要/总结阶段引用对话历史

• 背景：上下文窗口满了以后会触发摘要（给模型一个“新窗口+工作摘要”），但摘要是有损压缩，可能遗漏任务关键约束或细节。
• 做法：把对话历史也当作文件提供；摘要后如果模型发现细节缺失，可以在历史文件里搜索并找回。
• 价值：把“总结”从一次性不可逆的压缩，变成“摘要 + 可回溯原始证据”的组合，降低遗忘风险。

支持 Agent Skills 开放标准（把“怎么做”也文件化）

• 定位：Skills 是用文件描述的一组专用能力/操作指南（类似领域 SOP），包含名称与说明，可作为少量静态线索存在。
• 做法：静态上下文只保留“技能名/概述”，需要时再通过 grep/语义搜索把相关 Skill 文件动态加载进来。
• 价值：把专业流程与可执行脚本聚合为“可检索资产”；Agent 不必始终背着所有技能说明，而是在遇到对应任务时再精确加载。

高效地只加载“需要的 MCP 工具”

• 背景：MCP 用于访问 OAuth 资源（生产日志、设计稿、企业内部文档等）。但一些 MCP 服务器工具很多、描述很长，如果全部塞进提示词会显著占用上下文。
• 做法：把 MCP 工具描述同步到一个文件夹；静态上下文里只保留少量工具名称等线索，真正要用时再去文件里查具体描述。
• 数据点：文章提到一次 A/B 测试中，在会调用 MCP 工具的运行里，这个策略把总 token 消耗减少了 46.9%（统计显著，但会受已安装 MCP 数量波动影响）。
• 额外收益：文件还能承载“工具状态”（例如需要重新认证）。过去模型可能“忘了工具存在”，现在可以读到状态并主动提示用户处理认证问题。

把所有集成终端会话视为文件

• 痛点：以往需要手动复制粘贴终端输出给 Agent，既低效又容易遗漏上下文。
• 做法：Cursor 将集成终端输出自动同步到本地文件系统；Agent 把它当“可检索文件”按需读取/搜索。
• 价值：终端日志从“聊天里的一次性文本”变成“持久、可定位、可增量读取”的证据源，适合排错与回溯。

整体收益与落地启示

• Token 更省：不再把所有可能相关的信息常驻在上下文，改为“线索常驻 + 内容按需加载”。
• 质量更稳：减少无关/冲突信息进入上下文带来的干扰，让模型更聚焦于当前任务所需证据。
• 可追溯与可恢复：把工具输出、对话历史、终端日志、工具描述都“文件化”，让 Agent 能回到原始材料继续查证，而不是依赖一次性截断或纯摘要记忆。
• 面向复杂集成更友好：尤其是 MCP 这种“工具多、描述长、状态会变”的场景，用动态发现可以同时解决占用与可用性提示的问题。

Wide Research: Beyond the Context Window

• 文章链接：Wide Research: Beyond the Context Window

核心问题：上下文窗口瓶颈

问题现象
当要求 AI 研究多个实体（如 50 家公司、30 篇论文或 20 个竞品）时，会出现一个令人沮丧的现象：

• 第 1-5 项：模型执行真正的研究，检索信息、交叉引用来源，产出详细准确的分析
• 第 6-8 项：质量开始微妙下降，描述变得更通用，模型开始依赖先前模式而非新鲜研究
• 第 9 项以后：模型进入"编造模式"（fabrication mode），开始基于统计模式生成听起来合理但实际错误的内容

问题本质
这不是提示工程问题，也不是模型能力问题，而是一个架构约束问题。上下文窗口不仅要存储原始信息，还包括：

• 原始任务规范和要求
• 一致输出格式的结构模板
• 每个项目的中间推理和分析
• 交叉引用和比较笔记
• 所有先前项目的累积上下文

为什么更大的上下文窗口无法解决问题

博客指出了四个关键原因：

原因	说明
上下文衰减非二元	模型不会在整个上下文窗口内保持完美召回，存在"中间丢失"（lost in the middle）现象
处理成本不成比例增长	400K token 的处理成本不是 200K 的两倍，而是指数级增长
认知负载问题	即使有无限上下文，让单一模型在数十个独立研究任务中保持一致质量也会造成认知瓶颈
上下文长度压力	当助手消息内容超过一定阈值时，模型会自然倾向于匆忙总结或使用不完整的表达形式

解决方案：Wide Research 的架构转变

核心理念：并行处理

Wide Research 代表了对大规模研究任务的根本性重新思考——从单处理器、顺序范式转向并行处理架构。

动作原理

传统方式：单一 Agent 顺序处理所有项目
    ↓
Wide Research：多个专门的 Agent 并行处理各自的子任务

关键设计：

1. 任务分解：将大型研究任务分解为独立的子任务
2. 并行执行：多个 Agent 同时处理不同的研究项目
3. 独立上下文：每个 Agent 拥有自己的上下文窗口，不会相互干扰
4. 结果聚合：最后将各个 Agent 的研究结果汇总整合

优势

• 消除上下文压力：每个子任务在干净的上下文中执行
• 保持研究质量：第 50 个项目与第 1 个项目获得同等质量的研究
• 经济高效：避免了大上下文窗口的指数级成本增长
• 可扩展性：可以轻松扩展到更多研究项目

总结

Wide Research 的核心洞察是：上下文窗口限制是一个架构问题，需要架构级别的解决方案。通过将单一 Agent 的顺序处理转变为多 Agent 的并行处理，Manus 成功解决了 AI 研究工具在处理大规模任务时的"编造"问题，使 AI 能够在第 50 个研究项目上保持与第 1 个项目同样的准确性和深度。