随着大模型能力的边界不断拓展，我们构建智能体的方式正在经历一场静悄悄却剧烈的范式转移，核心不再是堆砌更复杂的提示词，而是学会如何优雅地让路。
Google DeepMind 工程师 Philipp Schmid，总结了 Manus 创始人 Peak Ji，LangChain 的工程师 Lance Martin 的实战经验，以及最新的行业研究，深度剖析了上下文工程（Context Engineering）的核心逻辑。
这并非一篇枯燥的技术文档，而是一份关于如何在六个月内通过五次代码重构，从复杂性泥潭中杀出重围的工程手记。
真正的智慧在于删繁就简，在于对抗模型的遗忘，在于用最精确的通信替代冗余的共享。
对抗上下文腐烂（Context Rot）
在探讨具体战术之前，我们需要重新审视我们手中的工具。
大语言模型并非全知全能的神，它更像是一个拥有惊人推理能力但短期记忆极度脆弱的大脑。
为了让这个大脑在复杂的现实任务中发挥作用，我们需要构建一套被称为智能体线束（Agent Harness）的软件系统。
线束之于模型，如同缰绳之于赛马。
它包裹着模型，管理着消息的历史循环，处理工具调用的执行逻辑，并负责所有的上下文逻辑。
在这个层面上，开发者不再仅仅是提示词的编写者，而是系统架构师。
我们面临的挑战不再是如何让模型说话，而是如何防止上下文腐烂（Context Rot）。
上下文腐烂是一个隐蔽的系统性风险。
许多模型宣称拥有百万级的上下文窗口，这让开发者产生了一种错觉，以为可以无限制地向模型灌输信息。
事实并非如此。
模型的有效上下文窗口往往远小于其标称上限，通常在 256k Token左右达到性能峰值。
一旦超越这个界限，即便未触及硬性上限，模型的推理能力也会断崖式下跌。
更致命的是上下文污染与混淆。
过多的无关信息如同噪音，淹没了关键指令；复杂的工具定义让模型在指令与数据之间迷失。
Manus 团队在半年的开发周期里，五次推倒重来，最终悟出的真理令人警醒：随着模型变得越来越强大，我们不应该搭建更复杂的脚手架，而应该学会做减法。
为了维持 Agent 的长期运行，我们必须学会遗忘。
但这并非盲目的删除，而是一场关于信息压缩的精细手术。
Manus 团队将上下文缩减策略提炼为两个核心维度：紧凑化（Compaction）与摘要化（Summarization）。
紧凑化是首选策略，它的核心价值在于可逆性。
在智能体与其环境的交互中，大量信息其实是冗余的。
当一个编程智能体刚刚编写并保存了一个 500 行的代码文件，在聊天记录中保留这 500 行代码就是对上下文资源的极度浪费。
系统应当做的是将这部分内容替换为文件已保存至 /src/main.py的路径信息。
这种处理方式极其高明。
它将庞大的文本内容卸载到了外部存储中，仅在上下文中保留了索引。
模型并没有真正遗忘这部分内容，它只是知道内容在哪里。
如果未来的任务需要读取代码，模型随时可以调用工具将内容重新加载回上下文。
这种以路径代内容的策略，在不损失任何信息精度的前提下，极大地释放了宝贵的注意力窗口。
当紧凑化仍不足以应对上下文压力时，摘要化作为一种有损压缩手段才会登场。
但这其中隐藏着一个极易被忽视的细节：节奏（Rhythm）。
许多开发者在使用摘要功能时，倾向于将所有历史交互一刀切地压缩成一段文本。
Manus 的经验表明，这种做法会破坏模型的惯性。
模型在生成输出时，很大程度上依赖于最近几次交互的格式和风格。
如果历史记录被完全抹平为一段枯燥的摘要，模型往往会丢失原有的输出格式，导致性能降级。
因此，正确的摘要策略应当是掐头去尾留中间。
将久远的历史总结为结构化的 JSON 数据，但必须保留最近几轮（例如最后 3 轮）工具调用的原始、全细节格式。
这就像是在接力赛中，虽然我们不再关注起跑时的姿势，但必须保持交接棒瞬间的速度和节奏。
优先级链条由此确立：首选保留原始数据，次选可逆的紧凑化，最后才是带有节奏保护的摘要化。
每一步都是为了在有限的窗口内，压榨出最高的智能密度。
隔离与通信：多智能体的协作哲学
当我们从单一智能体走向多智能体（Multi-Agent）系统时，架构设计的复杂度呈指数级上升。
一个最直观但错误的直觉是：让所有子智能体共享同一个庞大的上下文。
这种大锅饭式的内存共享看似高效，实则灾难。
它不仅带来了巨大的 KV-Cache（键值缓存）计算惩罚，增加了推理成本，更严重的是导致了严重的上下文污染。
想象一下，一个负责搜索网页的智能体，真的需要知道负责写代码的智能体之前的调试报错信息吗？这些无关信息只会成为干扰决策的噪音。
Manus 在这里借鉴了 Go 语言（GoLang）并发编程的经典格言：通过通信来共享内存，而不要通过共享内存来通信。
在智能体架构中，这意味着我们需要对任务进行严格的离散化处理。
对于输入输出明确的任务，例如在文档库中检索特定条款，系统应当启动一个全新的子智能体。
这个子智能体拥有一个完全空白的上下文，除了明确的指令外，不携带任何历史包袱。它就像一个被临时雇佣的特种兵，任务单纯，执行高效。
只有在处理极其复杂的推理任务，比如需要根据之前的长篇对话历史来调试代码逻辑时，我们才谨慎地选择共享上下文。
在这种视角下，共享上下文不再是默认选项，而是一种需要极力避免的昂贵依赖。
每一次分叉上下文（Forking Context），本质上都是在增加系统的熵，破坏缓存的连续性。
这种隔离机制不仅提升了各个子智能体的专注度，也让调试变得更加容易。
因为每个智能体的输入和输出都是清晰界定的，开发者可以像测试独立函数一样测试每个智能体的表现，而不必在庞大的对话历史中寻找故障的根源。
扁平化的行动空间：像程序员一样思考
工具是智能体的手脚。
给予模型何种工具，直接决定了它的行为模式。
这里存在一个误区：给模型提供尽可能多的工具，让它自己选择。
实验数据表明，当工具数量超过 100 个时，模型不仅会出现选择困难，更会产生严重的幻觉，开始捏造参数甚至调用不存在的工具。
为了解决这一问题，Manus 提出了一套层级化的行动空间（Hierarchical Action Space）设计方案。
这一方案将工具分为三个层级，构建了一个金字塔式的能力结构。
位于塔尖的是原子层（Atomic Level）。
这一层仅包含约 20 个最核心的工具，如文件读写、浏览器导航、搜索等。
这些工具是智能体生存的基础，必须保持高度的稳定性和通用性。
由于数量少且定义清晰，模型对这些工具的掌握程度极高，几乎不会出错。
位于中间的是沙盒实用程序（Sandbox Utilities）。
这是该架构最精彩的部分。
不要为每一个命令行工具（如 grep, ffmpeg, git）单独定义一个 LLM 工具。
相反，我们应该教会模型使用 Bash。
Manus 定义了类似mcp-cli <command>的通用接口，将具体的工具定义排除在上下文窗口之外。
这意味着，模型不再需要学习成百上千个特定工具的 API，它只需要学会像人类程序员一样，在终端中输入命令。
这不仅极大地减少了上下文的占用，更赋予了模型无限的扩展性。
只要是终端能运行的命令，模型就能使用，而无需重新修改工具定义。
位于底层的是代码/包层（Code/Packages）。
对于复杂的逻辑链条，比如获取城市列表 -> 遍历查询 ID -> 获取天气数据，我们不应让 LLM 通过三次往返对话来完成。
这太慢，且容易在中间环节出错。正确的做法是提供封装好的 Python 库，让 Agent 编写一个动态脚本，一次性执行完毕。
通过这种层级划分，我们将模型的认知负担降到了最低。它只需要在原子层做高层决策，在沙盒层调用通用能力，在代码层处理复杂逻辑。
Agent 即工具：去拟人化的组织架构
在设计多智能体系统时，我们很容易陷入拟人化的陷阱，设计出复杂的科层制组织架构：经理 Agent 指挥小组长 Agent，小组长 Agent 指挥执行 Agent。
这种层层汇报的机制在人类社会中或许有效，但在 AI 系统中却是效率的杀手。
Manus 的第五次重构得出结论：不要过度拟人化。Agent 即工具（Agent as Tool）才是最高效的模式。
对于主模型而言，制定计划或深度研究不应该是一个需要通过对话来协商的同事，而应该仅仅是一个被调用的函数。
当主 Agent 需要规划时，它调用call_planner(goal="...")。
线束在后台启动一个临时的规划子智能体，完成任务后返回一个结构化的 JSON 对象，而不是一段啰嗦的自然语言对话。
这种模式实际上是 MapReduce 思想在 Agent 领域的投射。
主 Agent 将任务分发（Map）给子 Agent，子 Agent 在独立的上下文中并行处理，最终将结果汇总（Reduce）返回。
整个过程对主 Agent 是透明的，它看到的只是一个函数调用的输入和输出。
这极大地扁平化了系统的复杂性。
数据在不同模块间的流转不再依赖于模糊的自然语言理解，而是变成了精确的结构化数据传递。
系统不再需要解析好的，老板，我这就去办这样的废话，而是直接处理{"status": "success", "data": {...}}。
苦涩的教训与最佳实践
在工程落地的深水区，Philipp Schmid 总结了一系列血的教训。这些经验不仅是技术指南，更是对 AI 发展规律的深刻洞察。
绝不要使用 RAG（检索增强生成）来管理工具定义。
这种做法听起来很诱人：根据当前任务动态检索最相关的工具。
但在实践中，这会导致工具列表在不同轮次间跳变，打破 KV 缓存，让模型产生精神分裂般的幻觉。
工具集应当是像基石一样稳定且明确的存在。
重读苦涩的教训（The Bitter Lesson）。
不要试图通过微调模型来获得短期优势，也不要针对特定的动作空间过度训练强化学习（RL）策略。
你今天辛苦获得的 5% 性能提升，很可能会被明天发布的下一代基础模型轻松碾压。
上下文工程应当是一个灵活的接口，旨在适应基础模型能力的提升，而不是将自己锁死在某个特定的模型版本上。
我们构建的是系统，而不是补丁。
建立严格的预腐烂阈值（Pre-Rot Threshold）监控。
如果你的模型上限是 100 万 Token，不要天真地等到 99 万时才开始处理。
性能的衰减往往在 256k 甚至更早的时候就已经开始。
开发者必须实时监控 Token 计数，在系统进入腐烂区之前，主动触发紧凑化或摘要化循环。
最后，通过实习生测试（The Intern Test）来验证系统。
放弃那些主观的、基于 LLM 打分的基准测试。
你应该关注那些计算可验证（Computationally Verifiable）的任务：生成的代码能编译通过吗？执行的命令产生了预期的文件吗？
在真实环境中，二进制的成功/失败指标远比看起来写得不错要有价值得多。
回顾这段技术演进，最令人深思的并非那些被添加的功能，而是那些被剔除的冗余。
Manus 删除了动态工具定义，拥抱了通用的 Shell；删除了繁琐的管理层级，采用了函数式的调用。
这正是上下文工程的终极奥义：在这个算力与智能爆炸的时代，我们构建的系统不应成为模型的束缚。
真正的工程智慧，在于寻找完成任务所需的最小有效上下文（Minimal Effective Context）。
就像米开朗基罗面对大理石时所做的那样，去掉多余的部分，剩下的就是艺术。
参考资料：
https://www.philschmid.de/context-engineering-part-2
