标签归档：AIAgent

关于 AI Agent 的思考：大模型边界和工作流

最近在体验一些 AI Agent 的产品，有一个比较感受：大多数的 AI Agent 最终都是一个或多个工作流，原本我们想象的那种完全自主、能够独立思考和决策的 AI Agent 很少。

从而也就无法看到一句话就完成所有的事情，需要有专业的人在旁边盯着。

甚至出现了一个新的名词：大模型善后工程师

并且那种自动多的 AI Agent ，面对的大多数是对于幻觉，有一定容错的场景，如自动化报告生成，陪伴语聊。

那些无法容错的场景， AI Agent 就必须要人工审核或者带审计的工作流来完成。

为什么在准确性要求比较高的 AI Agent 都变成了工作流？

看一下我们常见的 AI Agent 逻辑：

收到用户输入 → 判断意图 → 调用对应的模块 → 整理输出 → 返回结果

这跟我们想象中的 Agent 差距很大。理想中的 Agent 应该像一个真正的助手，能理解复杂的需求，自主规划执行路径，遇到问题能灵活调整策略。但现实是，大部分产品都在用固定的流程来约束 AI 的行为。

为什么会这样？核心原因是大模型本身的特性决定的。

大模型的能力边界在哪里

大模型确实很强大，但它有明确的能力边界。

第一个边界是可靠性。大模型的输出本质上是概率分布，每次生成都有不确定性。同样的输入，可能得到不同的输出。这种不确定性在聊天场景下可以接受，但在准确率要求比较高的生产环境中就是个大问题。比如一个财务报表分析的 Agent，我们是无法接受它今天说利润率是 15%，明天又说是 18%。

第二个边界是准确性。大模型的训练数据是有截止时间的，而且它没有实时获取信息的能力。更重要的是，它会产生幻觉——看起来很有道理，但实际上是错的。一个合同审核的 AI Agent，引用了一条根本不存在的法律条款，差点出事。

第三个边界是执行能力。大模型本质上是一个文本生成器，它不能直接操作系统、调用 API、访问数据库。所有这些能力都需要额外的工程实现。而一旦涉及到外部系统的调用，就必须有明确的权限控制和错误处理，这又把我们拉回到工作流的思路上。

第四个边界是成本。完全放开让大模型自主决策，意味着大量的 token 消耗。一个复杂任务可能需要多次推理、多次调用，成本会急剧上升。在我们做 AI Agent 之初，成本问题就是一个要着重考虑的问题。我最近用得比较多的编程 Agent，就因为成本问题，把之前的收费逻辑做了颠覆式的变化，作为一个用户，最直观的感受就是费用暴增。

使用工作流是一种现实

面对这些边界，工作流成了一个自然的选择。

工作流解决了可控性问题。通过预设的流程，我们能确保 AI 的行为在可控范围内。每一步该做什么、不该做什么，都有明确的定义。这对企业应用来说至关重要。没有哪个企业敢把关键业务交给一个完全不可控的系统。

工作流解决了准确性问题。在工作流的每个节点，我们可以加入验证和校准机制。比如在数据查询环节，直接调用数据库而不是让大模型猜测；在关键决策点，加入人工审核环节。这样既利用了大模型的能力，又避免了它的短板。

工作流还解决了成本问题。通过流程优化，我们可以精确控制大模型的调用次数和方式。简单的任务用小模型或规则引擎处理，复杂的任务才调用大模型。这种分层处理大大降低了运营成本。

更重要的是，工作流让产品可以迭代优化。每个环节的表现都可以监控和改进，哪里出问题就改哪里，而不是面对一个黑盒束手无策。

如何设计一个好的工作流 Agent

既然工作流是当前的现实，那怎么设计一个好的工作流 Agent？

  1. 任务拆解。把复杂的任务拆解成多个简单、明确的子任务。每个子任务都有清晰的输入输出定义。比如一个智能客服 Agent，可以拆解为：意图识别、信息提取、知识检索、答案生成、对话管理等模块。
  2. 模块化设计。每个模块独立开发和优化，通过标准接口连接。这样的好处是可以灵活替换和升级。今天用规则引擎的地方，明天可以换成机器学习模型；现在用 GPT-4 的地方，以后可以换成更合适的专用模型。
  3. 状态管理。工作流需要维护整个对话或任务的上下文状态。这不仅包括用户的历史输入，还包括中间结果、系统状态等。良好的状态管理是实现复杂交互的基础。
  4. 异常处理。每个环节都可能出错，需要有完善的异常处理机制。比如大模型返回了不合预期的结果怎么办？外部 API 调用失败怎么办？这些都需要提前考虑。
  5. 人机协同。在关键环节保留人工介入的接口。这不是技术不行，而是业务需要。很多场景下，人工审核是合规要求，也是质量保证。总得有人背锅不是，毕竟 AI 背不了锅。

工作流的局限性

工作流虽然解决了很多问题，但也有明显的局限性。

第一是灵活性不足。预设的流程很难应对所有情况，遇到流程外的需求就无能为力。这也是为什么很多 Agent 给人感觉很”笨”的原因——它只会按照固定的套路来。

第二是开发成本高。设计一个完善的工作流需要深入理解业务逻辑，每个流程都需要大量的开发和测试。而且业务变化时，工作流也需要相应调整，维护成本不低。

第三是用户体验的割裂感。用户能明显感觉到自己在跟一个程序打交道，而不是一个智能助手。特别是当工作流设计不够自然时，这种割裂感会更强。

预想可能的发展

尽管当前工作流是主流，但技术还在快速发展。

模型能力在提升。新一代的大模型在准确性、稳定性上都有改进。特别是针对特定领域的专用模型，表现越来越好。比最新上的 Qwen3-Max 就针对工作流，工具调用有了特别的优化。这为减少工作流的约束提供了可能。

工具调用能力在增强。Function Calling、Tool Use、MCP，以及最新的 SKILLS 等技术让大模型能更好地与外部系统交互。虽然本质上还是工作流，但流程可以更动态、更智能。

多模态融合带来新可能。不只是文本，图像、语音、视频等多模态信息的处理能力都在提升。这让 Agent 能处理更复杂的任务，提供更自然的交互。

强化学习和自主学习是长期方向。让 Agent 从交互中学习，不断改进自己的策略。虽然现在还不成熟，但这是实现真正自主 Agent 的关键。

产品化的思考

做 AI Agent 产品，技术只是一部分，更重要的是产品思维。

首先要明确定位。你的 Agent 是要解决什么问题？为谁解决？解决到什么程度？不要试图做一个万能的 Agent，那样最后什么都做不好。现在很火的小鹏的机器人，其有 80 个控制点，相对于宇树的 20 个控制点，其灵活性肯定要高一些，但是其场景和定位是完全不一样的，成本也不一样。

其次是场景选择。选择那些容错率相对高、价值明确的场景。比如内容创作辅助就比财务决策更适合当前的技术水平。在合适的场景下，即使是工作流 Agent 也能创造很大价值。

然后是预期管理。不要过度承诺，要让用户清楚产品的能力边界。与其说这是一个智能助手，不如说这是一个智能工具。合理的预期能减少用户的失望，提高满意度。

还要重视数据积累。每一次用户交互都是宝贵的数据。通过分析这些数据，我们能发现工作流的不足，找到优化的方向。数据驱动的迭代是产品成功的关键。

最后是成本控制。AI Agent 的运营成本不低，必须找到合理的商业模式。是订阅制还是按量付费？是 To B 还是 To C？这些都需要根据产品特性和市场情况来决定。

实践中的几个关键点

基于这段时间的观察和实践，有几个点特别重要。

第一，不要迷信技术。大模型很强大，但它不是银弹。很多问题用传统方法解决更高效、更可靠。关键是找到合适的技术组合。

第二，重视工程实现。一个好的想法到一个可用的产品，中间有大量的工程工作。提示词优化、结果解析、错误重试、性能优化，这些看似琐碎的工作往往决定产品的成败。

第三，持续迭代。AI Agent 产品很难一步到位，需要不断根据用户反馈来改进。建立快速迭代的机制，小步快跑，逐步逼近理想状态。

第四，关注安全和合规。AI 的不可控性带来了新的安全风险。数据隐私、内容安全、决策可解释性，这些都需要提前考虑。特别是在企业级应用中，合规往往是第一要求。

第五，建立评估体系。怎么衡量一个 Agent 的好坏？准确率、响应时间、用户满意度、成本效率，需要建立全面的评估指标。只有能量化，才能持续优化。

写在最后

做 AI Agent 产品这段时间，最大的感受是理想与现实的差距。我们都希望做出科幻电影里那样的 AI，但现实的技术约束让我们不得不妥协。

但这未必是坏事。工作流让 AI 变得可控、可靠、可用。在当前的技术条件下，一个设计良好的工作流 Agent，往往比一个不受约束的”智能” Agent 更有价值。

关键是要认清现实，在约束中寻找创新的空间。大模型的边界是客观存在的，但边界之内仍然有广阔的天地。工作流不是终点，而是通向更智能的 Agent 的必经之路。

技术在进步，产品在迭代，市场在成熟。今天的工作流 Agent，可能就是明天自主 Agent 的雏形。重要的不是等待完美的技术，而是用现有的技术创造价值，在实践中推动进步。

这个领域还很年轻，充满了可能性。无论是技术突破还是产品创新，都有大量的机会。保持理性的乐观，脚踏实地地推进，相信我们能做出真正有用的 AI Agent 产品。

毕竟，每一个伟大的产品，都是从不完美开始的。

以上。

AI Agent不够聪明，但 SaaS 公司可能是解药

最近经常会和 AI Agent 聊天，使用 AI 编程，并且也会和正在用 AI Agent 的朋友聊天，发现大家 AI Agent 的期待值和实际体验之间，存在着相当大的落差。

换句话说，大家觉得 Agent 不怎么聪明。

1. AI Agent 到底哪里不聪明

可能是以下的方面：

  1. 业务理解能力差。很多 AI Agent 看起来能对答如流，但一涉及到具体业务场景就开始答非所问。先不说原因，原因后面再细讲。
  2. 执行能力有限。在大家的预期中 AI Agent 应该能自主规划和执行任务，但实际上大部分所谓的 AI Agent 还停留在”问一句答一句”的阶段。我们想像中的一句话需求，如”帮我分析这份财报并生成投资建议”，大部分 AI Agent 是搞不定的，类似于 Manus 这种勉强可以的，但其结论是否能参考也是存疑的。
  3. 可控性差。我们一方面希望 Agent 有自主能力，能像人一样灵活处理问题；另一方面又希望它的行为可预测、可控制。这本身就是个悖论。结果就是，要么 Agent 太死板，只能按预设流程走；要么太「聪明」，经常做出一些让人意外的操作。
  4. 定制成本高。这本来不是聪明的问题，但这是聪明的代价，每个企业的业务都有自己的特殊性，要让 Agent 真正理解并适应这些特殊性，需要大量的定制化工作。但问题是，很多企业并没有这个技术能力或者预算来做深度定制。

2. 为什么会出现这些问题

我觉得主要是三方面的原因：

  1. 过高的预期。过去一年，AI Agent 的概念被炒得太热了。各种厂商都在宣传 Agent 能够”完全替代人工”、”自主完成复杂任务”。但实际上，现在的技术水平离这个目标还有很大距离。有的老板，听了厂商的宣传后，真的以为买个 Agent 产品就能替代掉几个员工。结果上线后发现，不仅没法替代人，反而需要专人来”照顾”这个 Agent，教它怎么工作，纠正它的错误。
  2. 模糊的产品定位。现在市面上的 Agent 产品，很多都想做成”万能助手”。但越是想什么都做，越是什么都做不好。反而是那些专注于特定场景的 Agent，比如专门做客服的、专门做数据分析的，效果会好很多。
  3. 技术栈的割裂。做好一个 Agent，需要模型能力、工程能力、业务理解能力的深度结合。但往往懂模型的不懂业务，懂业务的不懂模型，懂工程的可能两个都不太懂。这种割裂导致做出来的产品总是差那么一些。

3. 当前谁最有优势？

答案是：SaaS 公司。

在 AI Agent 落地上，SaaS 公司有着天然的优势。

SaaS 公司最大的优势是接近客户和数据。他们天天跟客户打交道，知道客户的真实需求是什么，痛点在哪里，实际的业务流程是怎样的。更重要的是，他们手里有大量的业务数据和场景数据，这些数据对于训练和优化 Agent 来说是无价之宝。

举个例子，一家做 CRM 的 SaaS 公司，如果要做销售 Agent，它有几个天然优势：

第一，它知道销售的真实工作流程是什么样的。不是理论上的流程，而是实际操作中的流程，包括各种例外情况和潜规则。

第二，它有大量的销售数据。什么样的话术转化率高，什么时间打电话效果好，不同行业的客户有什么特点，这些数据都在它的系统里。

第三，它有现成的客户界面。不需要重新教育客户怎么使用 Agent，可以直接嵌入到现有的产品里。

第四，它有持续优化的能力。客户每天都在使用它的产品，产生新的数据，这些数据可以用来持续优化 Agent 的表现。

相比之下，纯做 AI 的公司，虽然模型能力很强，但在落地时往往会遇到各种水土不服的问题。

4. 垂直场景的突破

在个人粗浅的认知中，Agent 的突破口在于垂直场景，而不是通用场景。在于需要 Konw-How 的场景。

为什么？因为垂直场景有几个优势：

第一，需求明确，专注。不需要 Agent 什么都会，只需要它把一件事做好就行。

第二，数据充足。垂直场景往往有大量的历史数据可以用来训练和优化。

第三，容错率高。因为场景固定，出现意外情况的概率较低，即使出现了也比较容易处理。

第四，ROI 清晰。在垂直场景下，Agent 的价值很容易量化。

比如法律文书撰写、行业分析、代码生成这些场景，都是合适的 Agent 应用场景。这些场景有明确的输入输出，有清晰的质量标准，有大量的历史数据，非常适合 Agent 来处理。

5. 可预测与可掌控的矛盾

在 ToB 场景下，企业客户最怕的就是不确定性。如果一个 Agent 今天的回答和明天的回答不一样，或者在关键时刻做出了意料之外的决策，那对企业来说不可接受的。

但是，客户又希望 Agent 有自适应能力，能够灵活处理各种情况。

当前的解决方案基本上是两个极端：

  1. 完全用 Workflow 来定义 Agent 的行为。每一步做什么都规定得清清楚楚，Agent 只是一个执行者。这样做的好处是完全可控，坏处是太死板，失去了 Agent 的灵活性。
  2. 完全放开，让 Agent 自己去学习和适应。这样做的好处是灵活，能处理各种意外情况，坏处是不可控，你永远不知道它下一步会做什么。

比较理想的方案应该是两者的结合：在关键决策点上用 Workflow 来控制，在具体执行上给 Agent 一定的自主权。但这说起来容易，做起来很难。需要对业务有深入的理解，知道哪些地方需要控制，哪些地方可以放开。

6. 模型能力 vs 工程能力

要解决这些矛盾和问题需要模型和工程两方面的提升，并且现阶段工程能力可能比模型能力更重要。

为什么？

因为现在的大模型能力其实已经不错了，GPT-5、Claude、DeepSeek 这些模型的理解和生成能力都很强。真正的瓶颈在于如何把这些能力转化成实际的业务价值。

这就需要大量的工程工作：

  • 如何设计合理的 Prompt，让模型理解业务需求
  • 如何构建知识库，让模型能够获取必要的信息
  • 如何设计工作流，让模型的输出能够被系统消费
  • 如何做异常处理，保证系统的稳定性
  • 如何做监控和优化，持续提升系统表现

这些工作属于比较累和碎的活儿，不如训练模型那么「高大上」，但却是 Agent 能否落地的关键。

7. 安全问题

AI Agent 的安全问题不仅仅是数据泄露，更大的问题在于，Agent 可能会做出一些不当的决策或者操作。

比如，一个有权限访问企业数据库的 Agent，如果被恶意引导，可能会删除重要数据或者泄露敏感信息。一个负责采购的 Agent，如果判断失误，可能会下错订单，造成巨大损失。如此种种……

现在的解决方案主要是加各种限制和审核机制，但这又回到了前面的矛盾：限制越多，Agent 就越不「智能」。

8. 可能的未来

基于目前的情况，我觉得接下来的一段时间 Agent 的发展会有几个趋势：

第一，从通用到垂直。越来越多的 Agent 会专注于特定的场景和行业。

第二，从替代到增强。Agent 的定位会从「替代人工」转变为「增强人工」。

第三，从单点到系统。不再是一个个孤立的 Agent，而是多个 Agent 协同工作的系统。

第四，从产品到服务。Agent 不再是一个买来就用的产品，而是需要持续优化的服务。

这些趋势意味着什么？

意味着 Agent 市场会越来越理性，泡沫会逐渐消失，真正有价值的应用会脱颖而出。

9. 最后

回到标题：AI Agent不够聪明

确实不够聪明，至少没有我们期望的那么聪明。

但这不意味着 Agent 没有价值。就像早期的计算机，虽然功能有限，但在特定场景下已经能创造巨大价值。关键是找到合适的场景，用合适的方式，解决真实的问题。

AI Agent 的发展还处于早期阶段，现在下结论还为时过早。但有一点是确定的：那些能够深入理解客户需求，扎实做好工程实施，持续优化产品体验的公司，最终会在这个市场上站稳脚跟。

至于 AI Agent 什么时候能真正「聪明」起来？我觉得还需要时间。可能是一年，可能是三年，也可能是五年。但在这个过程中，我们需要做的不是等待，而是不断探索、试错、优化，一步步接近那个目标。

毕竟，罗马不是一下子建成的，AI Agent 也不是。

以上。

从 LangChain 和 Manus 两巨头上下文工程实战中学到的 5 点经验

最近仔细看了 LangChain 的 Lance 和 Manus 的 Pete 的视频，主题是构建 AI 智能体中的上下文工程。这次分享没有那些空泛的理论，全是在生产环境中验证过的实战经验。

我结合自己的思考，整理了我认为 5 个最有价值的技术要点，每一个都直接影响着智能体的性能和可用性。

1. 上下文爆炸是智能体最大的瓶颈

Manus 统计显示，一个典型的智能体任务需要约 50 次工具调用。Anthropic 也提到，生产环境中的智能体对话可能持续数百轮。每次工具调用都会返回结果，这些结果会不断累积在消息历史中。

问题在于，随着上下文长度增加，模型性能会明显下降。Anthropic 把这个现象称为”上下文腐烂”（context rot）。具体表现是模型开始重复输出、推理速度变慢、回答质量下降。大部分模型在 200k Token 左右就开始出现这些问题，远低于它们宣称的上限。

这就形成了一个矛盾：智能体需要大量上下文来保持工作状态的连续性，但上下文太长又会导致性能下降。这是所有开发智能体的团队都会遇到的核心挑战。

Lance 在分享中展示了他们 Open Deep Research 项目的数据。这个开源项目在 Deep Research Bench 测试中排名前十，但即使是这样优秀的实现，也需要在三个阶段中不断地卸载和压缩上下文才能保持高效运行。

Pete 则分享了 Manus 的经验。他们发现，如果不做任何优化，上下文会在几十轮对话后就达到模型的处理极限。更糟糕的是，用户往往在这时才开始进入任务的核心部分。

解决这个问题没有捷径，必须从架构设计开始就考虑上下文管理。这也是为什么”上下文工程”这个概念在今年 5 月开始迅速流行的原因。它不是可选的优化项，而是构建生产级智能体的必要条件。

2. 上下文工程的五大组成部分

Lance 和 Pete 在分享中系统地总结了上下文工程的五个核心组成部分，这些部分相互关联，形成了一个完整的技术体系。

上下文卸载 是把部分信息移出主消息历史，存储到外部系统中。最常见的是使用文件系统。当搜索工具返回大量结果时，不是把完整内容放在消息队列里，而是写入文件，只在上下文中保留文件路径。Claude Code、Manus、Open Deep Research 项目都大量使用这种方法。

上下文缩减 包括压缩和摘要两种策略。压缩是去掉可以从外部重建的信息，摘要是对信息进行不可逆的精简。Claude 3.5 Sonnet 已经内置了修剪旧工具调用的功能。Cognition 在智能体交接时也会触发摘要。

上下文检索 解决如何按需获取被卸载的信息。有两派做法：Cursor 使用索引加语义搜索，Claude Code 和 Manus 只用文件系统加 grep、glob 这样的简单工具。两种方法各有优劣，选择哪种取决于具体场景。

上下文隔离 通过多智能体架构实现关注点分离。每个子智能体有自己的上下文窗口，避免信息混杂。Manus 的 Wide Agents、LangChain 的 Deep Agents、Claude 的多智能体研究员都采用了这种设计。

上下文缓存 利用 KV 缓存等机制减少重复计算。Anthropic 等服务商提供的缓存功能对长上下文智能体至关重要，特别是在输入远长于输出的场景下。

这五个部分不是独立的，而是相互影响的系统。卸载和检索让缩减更高效，稳定的检索让隔离变得安全。但隔离会减慢上下文传递，降低缩减频率。更多的隔离和缩减又会影响缓存效率。

Pete 特别强调，这种相互依赖意味着你不能只优化某一个方面，必须从整体考虑。比如，如果你的检索机制不够稳定，就不能激进地进行上下文隔离，否则子智能体可能无法获取必要的信息。

3. 上下文管理和数据库系统的对比

在分享中我个人的感觉是上下文工程的设计和数据库系统设计有比较多的相似性。

上下文卸载和数据库索引有很多相似之处，但它们的设计目标和实现机制存在本质差异。

展开来讲：相似性是都是为了解决容量与性能的矛盾

数据库索引解决的是「如何在海量数据中快速定位」的问题，而上下文卸载解决的是「如何在有限窗口中访问无限信息」的问题。两者都是通过建立某种间接引用机制，让系统能够处理超出直接处理能力的数据量。

数据库有内存中的索引页、磁盘上的索引文件、以及实际的数据页。上下文工程也有类似的层次：活跃上下文（相当于内存中的热数据）、文件路径引用（相当于索引）、文件系统中的完整内容（相当于磁盘数据）。

数据库索引针对不同的查询模式有不同类型：B 树索引适合范围查询，哈希索引适合等值查询，全文索引适合文本搜索。上下文卸载也有类似的分类：代码文件用路径索引，搜索结果用语义向量索引，对话历史用时间戳索引。

数据库的 buffer pool 会缓存频繁访问的索引页和数据页。上下文工程中的 KV 缓存也会保留频繁引用的上下文片段。两者都使用 LRU 或类似算法决定淘汰策略。

关键差异：索引是查询优化，卸载是容量管理

数据库索引的主要目标是加速查询，即使没有索引，全表扫描也能得到结果，只是慢一些。而上下文卸载是为了突破硬性限制，没有卸载机制，超出窗口的信息就完全无法访问。这是「优化」与「必需」的区别。

数据库索引是冗余信息，删除索引不会丢失数据，只会影响查询性能。但上下文卸载中，如果文件系统中的内容丢失，而上下文中只有路径引用，信息就永久丢失了。这就是为什么 Pete 强调卸载必须配合可靠的检索机制。

数据库索引需要随数据更新而维护，这是 ACID 事务的一部分。而上下文卸载通常是单向的：信息从上下文移到外部存储，很少需要反向更新。即使文件内容被修改，上下文中的引用通常保持不变。

数据库可以选择性地为某些列建立索引，基于查询模式和数据分布做决策。而上下文卸载往往是强制的：当接近 Token 限制时，必须卸载某些内容，没有”不建索引”的选项。

就像数据库有内存、磁盘、缓存的层次结构，上下文工程也有类似的分层：活跃上下文（内存）、文件系统（磁盘）、KV 缓存（缓存层）。数据库的查询优化对应着上下文检索，事务隔离对应着智能体隔离，数据压缩对应着上下文压缩。

Pete 提到的”通过通信”和”通过共享内存”两种模式，实际上对应着数据库中的消息传递和共享存储两种架构。当子智能体需要完整历史记录时，使用共享上下文模式，这就像数据库中的共享存储架构。当任务相对独立时，使用通信模式，类似于分布式数据库的消息传递。

智能体间的状态同步问题，本质上就是分布式系统的一致性问题。

Manus 的解决方案也借鉴了数据库的设计思想。他们使用结构化的模式（schema）来定义智能体间的通信接口，确保数据的一致性。他们的分层行为空间设计（函数调用、沙盒工具、软件包与API）类似于数据库的存储引擎分层。

这种类比不仅仅是理论上的相似。在实践中，你可以直接应用数据库系统的很多优化技术。比如，使用 LRU 策略决定哪些上下文应该被压缩或摘要；使用预写日志（WAL）的思想，在摘要前先把完整上下文写入日志文件；使用索引来加速文件系统中的信息检索。

我们可以借鉴数据库领域几十年的研究成果和工程实践，而不是从零开始摸索。

3. 上下文工程的核心是做减法，而不是加法

Pete 在分享最后强调的这一点可能是最重要的：避免上下文过度工程（context over-engineering）。

他提到，Manus 上线六七个月以来，最大的性能提升不是来自增加更复杂的上下文管理机制，而是来自简化架构、移除不必要的功能、对模型给予更多信任。他们已经重构了 Manus 五次，每次都是在做减法。

比如，早期的 Manus 使用 todo.md 文件来管理任务列表，结果发现约三分之一的操作都在更新这个列表，浪费了大量 Token。后来他们改用更简单的结构化规划器，效果反而更好。

另一个例子是工具选择。他们没有使用复杂的语义搜索来动态加载工具，而是固定使用 10-20 个原子功能，其他所有功能都通过沙盒中的命令行工具或 Python 脚本来实现。这种分层的行为空间设计，让系统既灵活又简单。

Pete 还提到了一个评估架构的方法：在强弱模型之间切换测试。如果你的架构从弱模型切换到强模型后能获得明显提升，说明架构有较好的未来适应性。因为明年的弱模型可能就和今天的强模型一样好。

关于是否要训练专门的模型，Pete 的观点也很明确：初创公司应该尽可能长时间地依赖通用模型和上下文工程。训练专门模型不仅成本高，而且在产品快速迭代的阶段，很可能在优化错误的指标。MCP（Model Context Protocol）的推出就是个例子，它彻底改变了 Manus 的设计，如果之前投入大量资源训练专门模型，这些投入就浪费了。

他们现在也不使用开源模型，不是因为质量问题，而是成本问题。对于输入远长于输出的智能体应用，KV 缓存至关重要。大型云服务商有更好的分布式缓存基础设施，算下来使用他们的 API 反而更便宜。

这些经验告诉我们：上下文工程的目标是让模型的工作变得更简单，而不是更复杂。不要为了优化而优化，每个设计决策都要基于实际的性能数据和用户反馈。

4. 压缩与摘要的本质区别决定了使用策略

Pete 详细解释了压缩和摘要这两种看似相似实则截然不同的策略，这个区分对实际应用至关重要。

压缩是可逆的。在 Manus 中，每个工具调用都有完整格式和紧凑格式。比如写文件操作，完整格式包含路径和内容，紧凑格式只保留路径。因为文件已经存在于文件系统中，通过路径可以随时恢复完整信息。这种可逆性至关重要，因为你永远不知道哪个历史操作会在后续变得重要。

摘要是不可逆的。一旦执行摘要，原始信息就永久丢失了。因此必须非常谨慎。Manus 的做法是在摘要前将完整上下文转储为日志文件，作为最后的保险。而且摘要时要保留最新几次工具调用的完整信息，让模型知道当前的工作状态。

关于阈值的确定，Pete 分享了具体数据：大多数模型在 200k Token 左右开始出现性能下降，他们将 128k-200k 设定为”腐烂前”阈值。这不是随意设定的，而是通过大量评估得出的。他们测试了不同长度下模型的重复率、推理速度、输出质量等指标。

触发策略是渐进式的：

  • 接近 128k 时，开始压缩最旧的 50% 工具调用
  • 压缩后检查实际释放的空间
  • 如果压缩效果不明显（因为即使紧凑格式也占用空间），才考虑摘要
  • 摘要时使用完整版本而非压缩版本的数据
  • 始终保留最新的几次完整工具调用

尽可能保留信息的完整性，只在必要时才接受信息损失。这就像数据压缩算法中的无损压缩和有损压缩，你总是先尝试无损方案。

不同类型的内容有不同的压缩潜力。搜索结果、API 响应这类内容压缩效果好，因为大部分信息可以通过查询重新获取。而用户的指令、模型的推理过程压缩空间有限，因为这些信息往往都是必要的。

5. 隔离策略的选择取决于任务特性而非直觉

多智能体隔离是个老话题，但 Pete 分享的经验推翻了很多常见做法。

首先是反模式的识别。很多团队喜欢按人类角色划分智能体：设计师智能体、程序员智能体、经理智能体等。Pete 明确指出这是个陷阱。这种划分源于人类组织的局限性（个人能力和注意力有限），而不是 AI 系统的最优设计。Manus 只有极少的几个功能性智能体：通用执行器、规划器、知识管理器。

关于隔离模式的选择，Pete 区分了两种场景：

通信模式适合结果导向的独立任务。主智能体发送明确指令，子智能体独立完成，返回结果。整个过程主智能体不关心细节，只要最终输出。比如”在代码库中搜索特定函数”、”将这段文本翻译成中文”。这种模式的优势是上下文干净、成本低、易于调试。

共享上下文模式适合需要完整历史信息的复杂任务。子智能体能看到所有历史对话和工具调用，但有自己的系统提示和工具集。比如深度研究任务，最终报告需要参考大量中间搜索和笔记。这种模式成本高（需要预填充大量上下文，无法复用 KV 缓存），但对某些任务是必要的。

判断使用哪种模式的关键是从结果推理过程的依赖性。如果最终输出强依赖于中间步骤的细节，就需要共享上下文。如果只需要最终结果，通信模式就足够了。

Pete 还提到了一个实用技巧：”智能体即工具”（agent as tool）。从主智能体视角，调用子智能体就像调用普通工具，有明确的输入输出接口。这简化了系统设计，也让调试更容易。Manus 的”高级搜索”功能就是这样实现的，表面上是个工具，实际是个完整的子智能体工作流。

他们解决通信问题的方法是强制使用结构化输出。主智能体调用子智能体前必须定义输出模式，子智能体通过专门的”提交结果”工具返回数据，系统用约束解码确保格式正确。这避免了自由格式通信带来的解析问题和信息丢失。

6. 一些额外的技术洞察

除了这五个核心经验，还有一些值得记录的技术细节。

信息的局部性。使用基于行的格式意味着每行都是独立的信息单元，读取第 100 行不需要解析前 99 行。这对于大文件的随机访问至关重要。

结构化不等于复杂格式。Pete 强调，他们优先使用基于行（line-based）的纯文本格式，而不是 JSON 或 XML。原因很简单：模型可以用 grep 搜索特定行，用 sed 修改特定内容，用 head/tail 读取部分数据。这些都是模型已经掌握的基础工具。

关于 Markdown 的使用要特别谨慎。虽然模型都接受过 Markdown 训练，但过度使用会带来副作用。某些模型会因此输出过多的项目符号和格式化标记，浪费 Token 还影响可读性。Manus 的经验是：在需要结构时用 Markdown，在存储数据时用纯文本。

关于模型切换的评估方法。Pete 提到，他们会在强弱模型间切换来评估架构的未来适应性。如果一个架构在弱模型上也能工作（虽然效果差一些），说明它不是过度依赖特定模型能力的脆弱设计。

关于工具数量的上限，他们的经验是不超过 30 个。这不是任意数字，而是基于大量测试。超过这个数量，模型开始频繁调用错误的工具，甚至调用不存在的工具。解决方案不是动态加载工具，而是设计分层的行为空间：少量原子工具 + 沙盒命令 + 代码执行。

关于评估体系，Manus 的三层评估值得借鉴：用户评分是北极星指标，自动化测试覆盖可验证的任务，真人评估处理主观性强的输出。学术基准测试只是参考，不能作为主要依据。

上下文工程不是一些零散的技巧，而是一个需要系统思考的工程领域。每个设计决策都会影响到其他部分，没有放之四海而皆准的最佳实践，只有基于具体场景的权衡取舍。

以上。