企业官网建设流程全解析

承德网站建设公司,做网站iiwok,贵阳网站推广￥做下拉去118cr,接网站建设外包的工作总结随着大模型能力的边界不断拓展#xff0c;我们构建智能体的方式正在经历一场静悄悄却剧烈的范式转移#xff0c;核心不再是堆砌更复杂的提示词#xff0c;而是学会如何优雅地让路。Google DeepMind 工程师 Philipp Schmid#xff0c;总结了 Manus 创始人 Peak Ji#xff0…随着大模型能力的边界不断拓展我们构建智能体的方式正在经历一场静悄悄却剧烈的范式转移核心不再是堆砌更复杂的提示词而是学会如何优雅地让路。Google DeepMind 工程师 Philipp Schmid总结了 Manus 创始人 Peak JiLangChain 的工程师 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