AI 代理上下文工程：Manus 经验应用于企业级知识问答系统

作者

https://infogaps.net/htmlpages/manus.html

要将 《AI 代理的上下文工程：构建 Manus 的经验教训》 一文中的经验教训应用于特定场景或技术栈，关键在于深入理解其核心原则，如保持提示稳定以优化 KV 缓存命中率、使用上下文感知状态机管理工具调用、利用文件系统或数据库作为外部记忆、通过 「复述」 或 todo 列表操纵模型注意力、保留错误信息助力模型自我修正与学习，以及警惕 「少样本陷阱」 并提供多样化示例。然后，针对目标应用场景 （如企业内部知识问答系统） 的具体需求和挑战，选择合适的技术栈 （如 Python 生态中的 LangChain 框架、 Flask/Django Web 框架、 OpenAI API 以及 Elasticsearch/Redis 等外部记忆与检索工具），并将这些原则系统地融入到系统设计、提示工程、状态管理、知识库构建、错误处理和示例数据准备等各个环节中。

1. Manus 的核心经验教训：上下文工程的关键原则

在构建 AI 代理，特别是像 Manus 这样的复杂系统时，上下文工程扮演着至关重要的角色。上下文工程不仅仅是简单地传递信息给大语言模型 （LLM），更涉及到如何高效、精准地构建、管理和利用上下文信息，以引导 AI 代理的行为，优化其性能，并控制成本。 Manus 团队在其实践过程中，总结出了一系列宝贵的经验教训，这些经验对于任何希望利用 LLM 构建高级 AI 应用 （尤其是企业级 AI 代理） 的开发者来说，都具有极高的参考价值 。这些原则涵盖了从提示设计、工具调用、记忆管理到错误处理和示例优化等多个方面，共同构成了 Manus 上下文工程的核心。 Manus 的创始人甚至将这种通过手动架构搜索、提示调整和经验猜测来优化上下文的过程戏称为 「随机梯度下降」 或 「随机研究生下降法」，虽然不够优雅，但非常有效 。

1.1 保持提示稳定，优化 KV 缓存命中率

在 AI 代理与大型语言模型 （LLM） 的交互过程中，尤其是在需要多轮对话和复杂工具调用的场景下，上下文信息的长度会迅速增长。 Manus 的经验指出，其典型任务平均需要约 50 次工具调用，导致输入与输出 token 的比例高达 100:1 。这种巨大的比例失衡使得预填充 （prefilling） 和解码 （decoding） 阶段的效率成为关键。幸运的是，具有相同前缀的上下文可以利用 KV（Key-Value） 缓存机制，从而显著降低首 token 延迟 （Time-To-First-Token, TTFT） 和推理成本，无论是使用自托管模型还是调用推理 API 。例如，使用 Claude Sonnet 模型时，缓存的输入 token 成本为 0.30 美元/百万 token，而未缓存的成本则高达 3 美元/百万 token，相差 10 倍之多 。因此，提高 KV 缓存命中率是上下文工程中至关重要的优化手段。

为了实现这一目标，Manus 总结了几个关键实践。首先，保持提示前缀的稳定性至关重要。由于 LLM 的自回归特性，即使提示中只有一个 token 的差异，也可能从该 token 开始使整个缓存失效。一个常见的错误是在系统提示的开头加入时间戳 （尤其是精确到秒的那种），虽然这能让模型知道当前时间，但也会让缓存命中率归零 。其次，确保上下文以追加方式增长，避免修改之前的动作或观察结果。同时，需要保证序列化的确定性，因为许多编程语言和库在序列化 JSON 对象时并不保证键的顺序稳定，这会在无声无息中破坏缓存 。最后，在某些模型提供方或推理框架不支持自动增量前缀缓存时，需要明确标记缓存断点。设置这些断点时，要考虑潜在的缓存过期问题，并至少确保断点包含系统提示的结尾 。如果使用 vLLM 等框架自行托管模型，还需要确保启用了前缀/提示缓存，并使用会话 ID 等技术在分布式工作节点间一致地路由请求 。这些细致的优化措施，共同构成了提升 KV 缓存命中率，进而降低延迟和成本的有效策略。

1.2 使用上下文感知状态机管理工具调用

随着 AI 代理能力的增强，其可用的工具数量往往会 「爆炸式增长」，尤其是在允许用户自行配置工具的情况下，可能会出现上百个工具被插入行动空间的情况 。这反而可能导致模型更容易选错动作，或走上低效的路线，使得 「全副武装的智能体变得更笨」 。一种自然的想法是设计一个动态的动作空间，例如通过类似 RAG（Retrieval Augmented Generation） 的方式按需加载工具。然而，Manus 的实践经验表明，除非绝对必要，否则应避免在迭代过程中动态增删工具 。主要原因有两点：首先，在大多数 LLM 中，工具定义在序列化后通常位于上下文的前部，任何变动都会使后续所有动作与观察的 KV 缓存失效；其次，当之前的动作和观察仍引用当前上下文中已不存在的工具时，模型会陷入混乱，容易导致模式违规或幻觉动作 。

为了解决这一挑战，Manus 采用了一种上下文感知的状态机来管理工具的可用性。该状态机并非真正移除工具，而是在解码阶段通过屏蔽相应 token 的 logits（模型输出的原始分数），从而根据当前上下文阻止 （或强制） 选择某些动作 。在实践中，许多模型提供商和推理框架支持某种形式的响应预填充，这使得开发者无需修改工具定义即可约束动作空间。例如，函数调用通常有三种模式 （以 NousResearch 的 Hermes 格式为例）：Auto（模型可选择是否调用函数，预填充回复前缀） 、 Required（模型必须调用函数，预填充到工具调用标记） 和 Specified（模型必须从特定子集中调用函数，预填充到函数名开头） 。 Manus 利用这一点，直接在 token logits 上施加掩码来限制动作选择。例如，当用户提供新的输入时，Manus 必须立即回复，而不能执行任何动作。此外，Manus 还为动作名称设计了统一的前缀 （例如，所有与浏览器相关的工具都以 browser_开头），从而能够轻松地在给定状态下限定智能体只能从某一组工具中选择，而无需依赖有状态的 logits 处理器 。这种设计有助于确保 Manus 智能体循环的稳定性，即使在以模型为驱动的架构下也是如此。

1.3 利用文件系统或数据库作为外部记忆

尽管现代前沿的大型语言模型 （LLM） 已经支持 128K 乃至更大的上下文窗口，但在真实的智能体场景中，这往往仍然不够用，有时甚至反而成为负担 。主要痛点包括：观测结果可能非常庞大 （例如与网页或 PDF 等非结构化数据交互时容易超出上下文限制）；模型性能在超过某个上下文长度后往往会下降；以及长输入成本高昂 （即使有前缀缓存，仍需为传输和预填充每个 token 付费） 。为了应对这些问题，许多智能体系统实现了上下文截断或压缩策略。然而，过度激进的压缩必然导致信息丢失。问题的本质在于，智能体必须基于所有先前状态来预测下一步行动，无法可靠地预测哪条观测在十步之后会变得至关重要。从逻辑角度看，任何不可逆的压缩都伴随风险 。

因此，Manus 将文件系统视为终极上下文：它具有容量无限、天然持久的特点，并且代理可以直接操作 。模型学会按需读写文件，把文件系统不仅当作存储，更当作结构化、外化的记忆。 Manus 的压缩策略始终保证可还原。例如，只要保留 URL，网页内容即可从上下文中移除；只要路径仍在沙盒中可用，文档内容也可省略。这使得 Manus 能在不永久丢失信息的前提下缩短上下文长度 。这种将文件系统作为外部记忆的策略，不仅解决了上下文窗口的限制问题，还为智能体提供了一种持久化、可扩展的记忆机制。在开发这一功能的过程中，Manus 的创始人甚至开始设想状态空间模型 （SSM） 在代理环境中高效运作的可能性。与 Transformer 不同，SSM 缺乏完整的注意力机制，难以处理长距离的反向依赖。然而，如果它们能够掌握基于文件的记忆——将长期状态外部化，而非保存在上下文里——那么它们的速度与效率或许就能催生一类全新的代理，甚至可能成为神经图灵机的真正继承者 。这一思考进一步凸显了外部记忆对于未来 AI 代理发展的重要性。

1.4 通过 「复述」 或 todo 列表操纵模型注意力

在处理复杂任务时，AI 代理很容易在冗长的上下文或复杂的决策过程中偏离主题或遗忘早期目标。 Manus 观察到，其典型任务平均需要约 50 次工具调用，这是一个相当长的循环，模型很容易在这个过程中迷失 。为了解决这个问题，Manus 采用了一种刻意设计的注意力操控机制：创建一个 todo.md 文件，并在任务推进过程中逐步更新，把已完成的项逐一勾选 。这并非一个无关紧要的 「卖萌」 行为，而是一种有效的策略，帮助模型在复杂的多步骤任务中保持对核心目标的聚焦。

这种通过 「复述」 或 todo 列表来操纵模型注意力的方法，其核心思想在于在上下文中明确维护一个动态的任务列表和进度。这个列表就像一个导航图，不断提醒模型当前的任务是什么，哪些步骤已经完成，哪些步骤尚待进行。通过这种方式，可以有效地引导模型的思考方向，防止其在处理大量中间信息和工具调用时偏离最初的用户意图。 todo.md 文件的存在，使得模型在每一步决策时都能回顾整体的任务框架，从而做出更符合最终目标的决策。这种方法简单却极具欺骗性，它通过显式地将任务分解和进度管理融入上下文，弥补了 LLM 在处理超长序列时可能出现的注意力分散问题。这种机制确保了即使在复杂的、多轮交互的任务中，AI 代理也能保持目标的一致性和执行的连贯性，是提升智能体在复杂任务中表现的有效手段。

1.5 保留错误信息，助力模型自我修正与学习

在 AI 代理的执行过程中，错误是不可避免的。然而，如何对待这些错误，对于智能体的学习和进化至关重要。 Manus 的经验表明，提升智能体行为最有效的方法之一，看似简单却极具欺骗性：把走错的路留在上下文中 。当模型看到一次失败的行动，以及随之而来的观察结果或堆栈跟踪时，它会潜移默化地更新其内部信念。这会将先验从类似的错误行动上移开，从而降低重蹈覆辙的概率 。事实上，Manus 团队认为错误恢复是真正具备智能体行为的最清晰指标之一，尽管在大多数学术研究和公开基准中，它仍然被低估，这些研究和基准往往聚焦于理想条件下的任务成功 。

保留错误信息并将其反馈给模型，是一种强大的在线学习机制。它允许模型从自身的错误中学习，而无需进行显式的重新训练或微调。当模型在上下文中看到之前的错误步骤及其负面反馈时，它会在后续的决策中倾向于避免类似的路径。这种机制不仅提升了模型的鲁棒性，也使其能够更好地适应动态变化的环境和未曾遇到过的新情况。通过将错误信息作为上下文的一部分，AI 代理能够进行更深入的 「思考」，分析失败的原因，并尝试不同的策略。这种自我修正和学习的能力，是智能体从简单的任务执行者向更高级的智能实体迈进的关键一步。因此，在设计和构建 AI 代理时，不应该害怕暴露错误，而是应该设计机制来捕获这些错误，并将其有效地融入模型的决策循环中，从而促进模型的持续改进和优化。

1.6 警惕 「少样本陷阱」，提供多样化示例

少样本提示 （Few-Shot Prompting） 是一种常用的提升 LLM 输出质量的技术，通过在提示中提供少量示例来引导模型的行为。然而，在智能体系统中，这种方法可能以微妙的方式适得其反 。语言模型是出色的模仿者，它们会模仿上下文中的行为模式。如果上下文中充斥着大量相似的动作-观察对，模型就会倾向于沿用这一模式，即便该模式已不再最优或适用于当前情况 。这在涉及重复性决策或任务的场景中尤为危险。例如，当使用 Manus 协助审阅一批 20 份简历时，代理往往会陷入一种节奏——仅仅因为上下文里出现了类似操作就不断重复。这可能导致行为漂移、过度泛化，甚至有时产生幻觉 。

为了解决这个问题，Manus 采用的方法是增加多样性。具体而言，Manus 在动作和观察中引入少量结构化变化，例如使用不同的序列化模板、替代表述方式、顺序或格式上的轻微扰动 。这种受控的随机性有助于打破固定模式，微调模型的注意力。换句话说，不要把自己困死在少量示例里，上下文越单一，Agent 就越脆弱 。通过提供多样化的示例，可以帮助模型更好地理解任务的边界和不同情况下的应对策略，而不是简单地复制粘贴之前的成功经验。这种策略鼓励模型进行更广泛的探索，并适应更复杂和多变的环境。在构建 AI 代理时，开发者应该有意识地设计多样化的提示示例，避免模型陷入局部最优或产生模式化的行为，从而提升其泛化能力和鲁棒性。

2. 应用场景：构建企业内部知识问答系统

企业内部知识问答系统是一个极具价值的 AI 代理应用场景。这类系统旨在帮助员工快速、准确地获取公司内部的各种信息，如规章制度、产品文档、操作流程、 HR 政策等。传统的企业内部信息获取方式往往效率低下，员工可能需要查阅大量的文档、邮件或咨询多个部门的同事才能找到答案。而基于 AI 代理的知识问答系统可以通过自然语言交互的方式，为员工提供一个统一、便捷的信息获取入口，从而显著提升工作效率和员工满意度。

2.1 场景需求与挑战

企业内部知识问答系统的核心需求是能够准确理解员工的自然语言提问，并从海量的企业内部知识库中检索出相关信息，生成简洁明了的答案。此外，系统还应具备一定的多轮对话能力，以便在用户问题不够明确时进行追问和澄清。同时，系统的回答必须准确可靠，避免传播错误或过时的信息。主要的挑战包括：

  1. 知识库的构建与维护：企业内部知识通常分散在不同的文档、数据库和系统中，如何有效地收集、整合这些异构数据源，构建一个统一、结构化的知识库是一个巨大的挑战。知识库还需要定期更新和维护，以确保信息的准确性和时效性。
  2. 自然语言理解的准确性：员工可能会以各种方式表达同一个问题，系统需要具备强大的自然语言理解能力，能够准确捕捉用户的真实意图，处理口语化、模糊甚至包含错误的提问。
  3. 上下文管理与多轮对话：在复杂的查询场景下，单轮问答往往无法满足需求。系统需要能够理解对话历史，维护上下文信息，进行有效的多轮交互，例如澄清问题、确认细节等。
  4. 回答的准确性与可靠性：对于企业内部的敏感信息或关键操作流程，回答的准确性至关重要。系统必须能够提供可靠的信息，并明确告知信息的来源和置信度，避免产生误导。
  5. 安全性与权限控制：企业内部信息通常具有不同的保密级别和访问权限。知识问答系统需要具备严格的安全机制和权限控制，确保员工只能访问其权限范围内的信息。
  6. 可解释性与可追溯性：系统应能解释其回答的依据，例如引用了哪些文档或数据。这对于建立用户信任和排查问题非常重要。

2.2 系统目标与核心功能

基于上述需求和挑战，企业内部知识问答系统的核心目标是构建一个高效、准确、可靠且易于使用的信息获取工具。其主要功能应包括：

  1. 自然语言提问接口：提供用户友好的自然语言输入界面，支持文本和语音输入。
  2. 意图识别与槽位填充：准确识别用户的提问意图，并提取关键信息 （槽位） 。
  3. 知识检索：根据用户意图和提取的关键信息，从企业内部知识库 （如 Elasticsearch 、数据库、文档管理系统等） 中快速检索相关信息。
  4. 答案生成：基于检索到的信息，利用大型语言模型生成简洁、准确、自然的回答。
  5. 多轮对话管理：维护对话状态和上下文信息，支持澄清式提问、上下文相关的后续提问等。
  6. 信息溯源与置信度展示：提供回答所依据的信息来源 （如文档链接、章节号），并展示答案的置信度。
  7. 用户反馈机制：允许用户对答案进行评价 （如 「有帮助」 、 「无帮助」），收集用户反馈以持续优化系统。
  8. 权限管理与数据安全：集成企业身份认证系统，根据用户角色和权限控制信息的访问。
  9. 知识库管理后台：提供管理界面，方便管理员导入、更新、审核知识库内容，监控系统运行状态。
  10. 与现有系统集成：能够与企业现有的 OA 系统、 HR 系统、 CRM 系统等进行集成，实现更广泛的信息获取和任务处理能力。

通过实现这些功能，企业内部知识问答系统可以显著提升员工获取信息的效率，降低信息查找成本，并促进企业内部知识的共享和利用。

3. 技术栈选择：Python 生态的威力

在构建企业级 AI 代理，特别是企业内部知识问答系统时，选择合适的技术栈至关重要。 Python 凭借其丰富的库、框架和活跃的社区，成为 AI 应用开发的首选语言之一。结合 LangChain 等框架，可以高效地实现 AI 代理的核心功能，并与各种大语言模型、数据存储和外部工具进行集成。

3.1 Python 作为核心编程语言

Python 因其简洁的语法、强大的生态系统以及在数据科学和机器学习领域的广泛应用而备受青睐。对于企业内部知识问答系统，Python 提供了以下优势：

  1. 丰富的 AI/ML 库：Python 拥有诸如 NumPy 、 Pandas 、 Scikit-learn 、 TensorFlow 、 PyTorch 等众多成熟的库，方便进行数据处理、模型训练和评估。
  2. 自然语言处理 （NLP） 工具：NLTK 、 spaCy 、 Gensim 等库为文本预处理、分词、实体识别、语义分析等 NLP 任务提供了强大的支持 。
  3. Web 开发框架：Flask 、 Django 等轻量级或全栈 Web 框架使得快速构建系统 API 和用户界面成为可能 。
  4. 数据库连接与操作：Python 提供了对各种数据库 （如 SQLite 、 PostgreSQL 、 MySQL 、 MongoDB 、 Elasticsearch） 的良好支持，方便进行数据的存储和检索。
  5. 异步编程支持：Asyncio 等库使得处理并发请求和 I/O 密集型操作 （如调用外部 API） 更加高效，这对于需要快速响应的问答系统尤为重要。
  6. 庞大的社区和资源：Python 拥有一个庞大且活跃的开发者社区，提供了大量的开源项目、教程和解决方案，遇到问题时更容易获得帮助。
  7. 可移植性和易部署性：Python 代码可以在多种平台上运行，容器化技术 （如 Docker） 使得 Python 应用的部署和管理更加便捷。

在企业内部知识问答系统中，Python 可以用于实现从数据预处理、模型集成、业务逻辑处理到 API 接口开发等各个环节。例如，可以使用 Python 脚本将企业内部的各种文档 （PDF 、 Word 、 Excel 等） 转换为文本格式，进行清洗和结构化处理，然后存入知识库。在问答环节，Python 可以调用 LangChain 等框架，与大语言模型交互，处理用户输入，并生成回答。

3.2 LangChain 框架的应用

LangChain 是一个开源的、用于构建由大型语言模型驱动的应用程序的框架。它提供了一系列模块化的工具和接口，简化了 AI 代理的开发流程，特别是在上下文管理、工具调用、链式调用等方面表现出色。在企业内部知识问答系统中，LangChain 可以发挥以下关键作用：

  1. 与大语言模型 （LLM） 的集成：LangChain 支持与多种 LLM（如 OpenAI 、 Hugging Face Hub 、 Anthropic 等） 的对接，提供了统一的接口，方便切换和比较不同模型的性能 。
  2. 提示模板管理：LangChain 允许开发者定义和管理提示模板，将用户输入、上下文信息、工具描述等动态地注入到提示中，从而更有效地引导模型行为 。
  3. 链 （Chains） 的构建：LangChain 的核心概念之一是 「链」，它允许将多个 LLM 调用或其他操作按照特定顺序组合起来，实现更复杂的任务。例如，可以构建一个检索问答链 （RetrievalQA chain），该链首先从知识库中检索相关文档，然后将这些文档作为上下文与用户问题一起传递给 LLM 生成答案。
  4. 代理 （Agents） 的实现：LangChain 提供了构建代理 （Agents） 的工具，代理可以根据用户输入和当前上下文自主选择和执行工具。这对于需要多步骤推理或调用外部 API 的任务非常有用 。例如，一个问答代理可以先调用搜索工具查找信息，如果找不到，再调用数据库查询工具。
  5. 记忆 （Memory） 模块：LangChain 提供了多种记忆组件，用于存储和检索对话历史，从而实现多轮对话功能。例如，ConversationBufferMemory 可以保存完整的对话记录，而 ConversationSummaryMemory 则可以保存对话的摘要，以适应不同长度的上下文窗口 。
  6. 索引 （Indexes） 与检索器 （Retrievers）：LangChain 集成了多种文本分割方法、向量存储后端 （如 FAISS 、 Chroma 、 Elasticsearch） 和检索算法，方便开发者构建高效的文档检索系统，这是知识问答系统的核心组件之一。
  7. 回调 （Callbacks） 与日志记录：LangChain 提供了回调系统，允许开发者在 LLM 调用、工具执行等不同阶段插入自定义逻辑，方便进行日志记录、监控和调试。

通过使用 LangChain，开发者可以更专注于业务逻辑和上下文工程的设计，而不是底层的模型调用和流程控制细节。例如，在构建企业知识问答系统时，可以利用 LangChain 的 RetrievalQA 链，结合 Elasticsearch 作为向量存储，快速搭建一个基于检索增强生成 （RAG） 的问答服务 。 LangSmith 等工具还可以帮助开发者调试、测试和监控 LangChain 应用的性能 。

3.3 Web 框架选择：Flask/Django

为了将企业内部知识问答系统提供给用户使用，需要构建一个 Web 应用程序，提供用户界面和 API 接口。 Python 的 Web 框架，如 Flask 和 Django，是实现这一目标的理想选择。

  1. Flask：Flask 是一个轻量级的 Web 框架，它提供了构建 Web 应用所需的核心功能，同时保持了高度的灵活性和可扩展性。它非常适合构建小型到中型的 API 服务和微服务。
    • 优势：简单易学、灵活、可扩展性强、拥有丰富的扩展库。
    • 适用场景：当需要快速构建一个 API 接口，或者项目结构相对简单时，Flask 是一个不错的选择。例如，可以创建一个 Flask 应用，暴露一个接收用户问题并返回 AI 生成答案的 API 端点。
    • 示例：可以使用 Flask 创建一个简单的 REST API，前端通过 AJAX 调用该 API 获取问答结果 。
  2. Django：Django 是一个功能齐全的全栈 Web 框架，它遵循 「包含所有必需品」 的理念，提供了 ORM 、模板引擎、表单处理、用户认证、后台管理界面等众多内置功能。
    • 优势：功能全面、内置组件丰富、安全性高、社区活跃、适合快速开发复杂的 Web 应用。
    • 适用场景：当需要构建一个功能复杂、需要数据库交互、用户管理和后台管理界面的企业级应用时，Django 更为合适。例如，企业内部知识问答系统可能需要用户登录、权限管理、知识库内容管理等功能，Django 可以很好地支持这些需求。
    • 示例：一些智能客服系统项目选择 Django 作为后端框架，利用其 ORM 管理数据库模型，并构建管理后台 。

选择 Flask 还是 Django 取决于项目的具体需求和团队的熟悉程度。对于主要提供 API 服务的问答系统，Flask 可能更轻便；而对于需要完整后台管理和复杂业务逻辑的系统，Django 可能更高效。无论选择哪个框架，Python 都能提供强大的支持。

3.4 大语言模型接入：OpenAI API

大型语言模型 （LLM） 是企业内部知识问答系统的核心引擎，负责理解用户问题、检索相关信息并生成自然语言回答。 OpenAI API 提供了对 GPT 系列等先进 LLM 的访问，是构建此类系统的常用选择。

  1. 模型选择：OpenAI 提供了多种模型，如 GPT-3.5-turbo 、 GPT-4 、 GPT-4o 等，它们在能力、成本和速度上有所不同。企业可以根据自身需求和预算选择合适的模型。例如，对于一般性的问答任务，GPT-3.5-turbo 可能已经足够，而对于需要更高推理能力的复杂任务，则可能需要 GPT-4 或更高版本的模型 。
  2. API 调用：通过 OpenAI 的 Python SDK，可以方便地调用 Chat Completions API 或 Assistants API 与模型进行交互 。
    • Chat Completions API：适用于一般的对话场景，开发者需要自行管理对话历史和上下文。
    • Assistants API：OpenAI 在 2023 年底推出的新 API，提供了更完整的对话管理、文件处理和工具调用能力，特别适合构建复杂的企业应用 。它内置了对话线程管理，简化了状态追踪和上下文管理。
  3. 企业级功能与安全性：OpenAI 为企业客户提供了一系列增强功能，包括数据隐私保护 （承诺不使用客户数据进行模型训练） 、静态和传输中数据加密、单点登录 （SSO） 、以及符合 CCPA 、 CSA STAR 、 SOC 2 Type 2 、 HIPAA 等合规性要求 。这对于处理企业内部敏感信息至关重要。
  4. 微调 （Fine-tuning）：对于特定行业或企业，可以使用 OpenAI 的微调功能，在自有数据上进一步训练基础模型，以提升模型在特定任务上的性能和风格一致性 。
  5. 成本管理：使用 OpenAI API 会产生费用，企业需要关注 Token 使用量和 API 调用成本。合理的上下文设计、缓存策略以及对 API 调用的监控都有助于控制成本 。

在企业内部知识问答系统中，可以将用户的问题和从知识库检索到的上下文信息一起发送给 OpenAI API，然后解析 API 返回的模型生成内容作为答案。 LangChain 等框架也内置了对 OpenAI API 的封装，使得集成更加便捷 。

3.5 外部记忆与检索：Elasticsearch/Redis

为了克服 LLM 上下文窗口的限制，并提供准确和最新的信息，企业内部知识问答系统需要依赖外部记忆和高效的检索机制。 Elasticsearch 和 Redis 是两种常用的技术选择。

  1. Elasticsearch：
    • 功能：Elasticsearch 是一个分布式的、可扩展的搜索和分析引擎，基于 Apache Lucene 构建。它以其快速的全文搜索、结构化搜索、分析以及高可用性而闻名。
    • 在知识问答系统中的应用：
      • 知识库存储与检索：可以将企业内部的结构化和非结构化文档 （如产品手册、政策文件、技术文档） 索引到 Elasticsearch 中。利用其强大的全文检索、模糊搜索、同义词扩展、高亮显示等功能，可以快速找到与用户问题相关的文档片段 。
      • 向量搜索 （Vector Search）：结合文本嵌入模型 （如 OpenAI 的 Embeddings API 或本地部署的 Sentence Transformers 模型），可以将文档转换为向量，并存储在 Elasticsearch 的 dense_vector 字段中。当用户提问时，将问题也转换为向量，然后利用 Elasticsearch 的向量相似度搜索功能 （如余弦相似度） 找到最相关的文档。这种基于语义的检索方式 （即检索增强生成，RAG） 可以显著提升问答的准确性 。
      • 混合搜索 （Hybrid Search）：Elasticsearch 支持将关键词搜索 （BM25） 和向量搜索的结果进行结合，取长补短，进一步提升检索效果 。
    • Python 集成：elasticsearch-py 和 elasticsearch-dsl 等 Python 库提供了与 Elasticsearch 集群交互的便捷方式，方便进行索引创建、文档插入、查询构建等操作 。
  2. Redis：
    • 功能：Redis 是一个开源的内存数据结构存储，常用作数据库、缓存和消息代理。它支持多种数据结构，如字符串、哈希、列表、集合、有序集合等，并提供了丰富的操作命令。
    • 在知识问答系统中的应用：
      • 缓存：Redis 可以作为缓存层，存储频繁访问的数据或计算结果，以减少对后端数据库或 LLM API 的调用，从而降低延迟和成本。例如，可以缓存常见的问答对、用户会话信息、 LLM API 的响应等。
      • 会话状态管理：Redis 可以用来存储用户的会话状态和短期对话历史，确保在多轮对话中上下文信息的连贯性和准确性。

4. Manus 经验在企业知识问答系统中的具体应用与实践

将 Manus 在上下文工程方面的经验教训应用于企业知识问答系统，可以显著提升系统的智能化水平和用户体验。这需要从提示工程、状态管理、知识库构建、注意力引导、错误处理和数据多样性等多个维度进行细致的考量和实践。通过借鉴 Manus 的成功经验，企业可以构建出更理解用户意图、更准确回答问题、更能处理复杂场景的知识问答 AI 代理。

4.1 提示工程与 KV 缓存优化策略

在企业知识问答系统中，有效的提示工程是确保 AI 代理准确理解用户问题并生成高质量回答的关键。借鉴 Manus 保持提示稳定以优化 KV 缓存命中率的经验，我们可以设计一套规范的提示模板。这些模板应包含系统角色设定 （例如，「你是一个专业的 XX 企业客服助手」） 、核心指令 （例如，「请根据以下信息回答问题」） 、上下文占位符 （用于注入对话历史、检索到的知识等） 以及输出格式要求。通过尽可能保持提示中静态部分 （如角色设定、核心指令） 的稳定，可以增加 LLM 在处理相似请求时 KV 缓存的命中率，从而提高响应速度并降低 API 调用成本。例如，对于常见问题类型，可以预定义一些高质量的提示模板。当用户提问时，系统首先对问题进行分类，然后选择合适的模板，并将用户的具体问题和检索到的相关知识动态填充到模板的相应位置。此外，还可以借鉴 Manus 对提示词进行系统化、模块化设计的经验，将复杂的提示拆解为多个可复用的组件，例如，将工具描述、操作规则、输出格式要求等分别模块化 。这不仅有助于提高 KV 缓存的效率，也使得提示的维护和迭代更加便捷。同时，需要关注提示的长度，避免不必要的冗余信息，确保传递给 LLM 的上下文是精炼且相关的，这也有助于提升 KV 缓存的利用率和模型的推理效率。

4.2 上下文感知的工具调用与状态管理

企业知识问答系统往往需要调用内部工具或 API 来获取实时信息或执行特定操作，例如查询订单状态、获取产品库存、调用 CRM 系统等。借鉴 Manus 使用上下文感知状态机管理工具调用的经验，我们可以为 AI 代理设计一个灵活且健壮的工具调用机制。首先，需要明确定义每个工具的功能、输入参数、输出格式以及调用前提条件。在 Python 技术栈中，可以利用 LangChain 等框架提供的工具抽象层来封装这些工具 。当 LLM 决定调用某个工具时，系统需要根据当前的上下文 （如用户意图、已识别的实体、对话历史等） 来准备工具调用所需的参数。例如，如果用户问 「我的订单 12345 到哪里了？」，系统需要先从用户问题中提取订单号 「12345」，并将其作为参数传递给 「查询订单状态」 的工具。状态管理在此过程中至关重要。需要维护一个会话级别的状态机，跟踪当前对话的进展、已执行的操作、获取到的信息等。这个状态机可以帮助 AI 代理决定下一步该做什么，例如，在获取到订单状态后，是直接回复用户，还是需要进一步调用其他工具获取物流详情。 Manus 通过事件流上下文 （对话、动作、观察） 和文件持久化 （如 todo.md） 来管理记忆与状态 。在企业知识问答系统中，可以使用数据库 （如 Redis） 来存储和管理会话状态，确保在多轮对话中上下文信息的连贯性和准确性。这种上下文感知的工具调用和状态管理，能够使 AI 代理更智能地处理复杂查询，提供更精准和个性化的服务。

4.3 利用 Elasticsearch 构建和检索外部知识库

企业知识问答系统的核心能力之一是基于企业内部积累的大量文档、数据和知识来回答用户问题。借鉴 Manus 利用文件系统或数据库作为外部记忆，并通过 RAG（检索增强生成） 技术增强模型能力的经验 ，我们可以利用 Elasticsearch 来构建和管理外部知识库。首先，需要收集和整理企业内部的各种知识资源，如产品手册、技术文档、 FAQ 列表、政策文件、历史工单等。这些文档经过预处理 （如文本提取、分段、清洗） 后，通过嵌入模型 （embedding model） 转换为向量表示，然后存储到 Elasticsearch 的索引中。当用户提出问题时，系统首先将用户问题也转换为向量，然后在 Elasticsearch 中进行相似度搜索，快速检索出与问题最相关的若干文档片段。这些检索到的片段作为额外的上下文信息，与原始用户问题一起构建成提示 （Prompt），输入给 LLM 生成最终答案。这种 RAG 机制不仅能够显著提高回答的准确性和相关性，还能让 LLM 基于最新的、特定的企业知识进行回答，克服了 LLM 本身知识截止和通用性过强的问题。为了优化检索效果，可以调整 Elasticsearch 的查询策略、相似度算法以及索引结构。同时，需要定期更新知识库索引，确保其内容的新鲜度和准确性。通过这种方式，企业知识问答系统能够充分利用已有的知识资产，为用户提供高质量、专业化的信息服务。

4.4 实现动态 todo 列表以引导模型注意力

在处理复杂或多步骤的用户查询时，有效地引导 AI 代理的注意力至关重要。借鉴 Manus 通过todo.md 文件来规划任务、跟踪进度并操纵模型注意力的经验 ，我们可以在企业知识问答系统中实现一个动态的 「任务列表」 或 「待办事项列表」 。当用户提出一个需要多个步骤才能完成的请求时 （例如，「帮我申请一个新产品试用，并安排工程师下周一下午进行安装培训」），AI 代理首先将这个大任务分解为一系列有序的子任务，并将这些子任务记录在动态的 todo 列表中。例如，这个列表可能包含：「1. 验证用户身份和权限；2. 查询新产品试用资格；3. 创建试用申请工单；4. 确认工程师可用时间；5. 预约安装培训」 。这个 todo 列表不仅为代理自身提供了清晰的行动指南，也可以作为重要的上下文信息传递给 LLM 。在每一轮交互中，LLM 可以查看当前的 todo 列表，了解哪些任务已经完成，哪些是下一步需要处理的，从而将其注意力集中在当前最相关的子任务上。当一个子任务完成后，系统会更新 todo 列表的状态。这种机制有助于 AI 代理在处理复杂流程时保持条理清晰，避免遗漏关键步骤或偏离主题。在 Python 实现中，这个 todo 列表可以是一个内存中的数据结构，也可以持久化到数据库或文件中，以便在长时间运行或跨会话的任务中保持状态。通过动态管理和利用 todo 列表，可以显著提升 AI 代理处理复杂、多轮交互任务的能力和可靠性。

4.5 错误处理与反馈机制的设计

在 AI 代理的运行过程中，错误是不可避免的。借鉴 Manus 保留错误信息以助力模型自我修正与学习的经验，企业知识问答系统需要设计完善的错误处理和反馈机制。当 AI 代理在处理用户请求或调用工具时发生错误，系统不应简单地报错或停止运行，而应尝试捕获错误信息，分析错误原因，并采取相应的恢复措施。例如，如果调用一个内部 API 失败，系统可以记录错误日志 （包括错误码、错误信息、请求参数等），并尝试重试、回退到备用方案，或者向用户提供友好的错误提示，并建议下一步操作。这些错误日志是宝贵的调试和改进资源，可以帮助开发团队识别系统中的薄弱环节并进行优化。同时，用户反馈也是提升系统性能的重要途径。系统应提供便捷的渠道让用户对 AI 代理的回答进行评价 （如 「有帮助/无帮助」 按钮） 或提供更具体的反馈意见。这些反馈信息可以与错误日志一起，用于后续的模型微调、提示工程优化和知识库更新。例如，如果多个用户都反馈某个问题的回答不准确，系统可以标记该问题，并触发人工审核或知识库更新流程。通过建立一个闭环的错误处理和反馈学习系统，企业知识问答 AI 代理能够持续学习和改进，不断提升服务质量和用户满意度。

4.6 提供丰富多样的示例数据

为了确保 AI 代理能够准确理解和处理各种用户输入，并提供高质量的响应，提供丰富多样的示例数据至关重要。这包括用于意图识别、实体提取、对话管理以及工具调用的训练数据和 few-shot 示例。借鉴 Manus 警惕 「少样本陷阱」 并提供多样化示例的经验，企业在构建知识问答系统时，应投入足够精力收集和整理覆盖各种业务场景和用户问法的示例数据。例如，在训练意图识别模型时，需要为每个意图提供足够数量且具有代表性的用户表述，包括不同的措辞、口语化表达、以及包含干扰信息的情况。对于 few-shot learning，即在提示中提供少量示例来引导 LLM 的行为，选择高质量、多样化的示例尤为关键。这些示例应能清晰地展示期望的输入输出格式、推理过程以及如何处理边界情况。例如，在定义调用某个特定工具的 few-shot 示例时，可以提供正常调用成功的例子，也要提供参数缺失、参数错误或工具不可用等情况下的处理示例。通过提供丰富多样的示例数据，可以帮助 AI 代理更好地泛化到未见过的用户输入，提高其鲁棒性和适应性。此外，定期回顾和更新示例数据，加入新的用户问法和业务场景，也是保持 AI 代理性能持续提升的重要环节。

5. 基于 Python 和 LangChain 的实现代码示例 （概念性）

为了更具体地展示如何将 Manus 的经验教训应用到 Python 技术栈中，我们可以构思一个基于 LangChain 框架的企业内部知识问答 AI 代理的简化实现。这个示例将重点关注上下文管理、工具调用和外部记忆的基本原理。

5.1 初始化 LLM 与核心组件

在 LangChain 中，首先需要初始化所选用的大语言模型 （LLM） 。对于 OpenAI 的模型，可以使用 ChatOpenAI 类。同时，还需要定义一些核心组件，例如记忆模块 （Memory） 和提示模板 （PromptTemplate） 。

from langchain.chat_models import ChatOpenAI
from langchain.memory import ConversationBufferMemory
from langchain.prompts import PromptTemplate, ChatPromptTemplate, MessagesPlaceholder
from langchain.schema import SystemMessage, HumanMessage, AIMessage

# 初始化 LLM，这里以 gpt-3.5-turbo 为例
llm = ChatOpenAI(model_name="gpt-3.5-turbo", temperature=0)

# 初始化记忆模块，用于存储对话历史
memory = ConversationBufferMemory(memory_key="chat_history", return_messages=True)

# 定义系统提示，这部分相对稳定，有助于 KV 缓存
system_prompt = SystemMessage(content="你是一个 AI 助手，负责在企业内部知识库中查找并回答员工的问题。")

# 定义主提示模板，包含系统消息、对话历史和用户问题
prompt = ChatPromptTemplate.from_messages([
    system_prompt,
    MessagesPlaceholder(variable_name="chat_history"), # 对话历史将动态注入
    HumanMessage(content="{user_input}"), # 用户输入将动态注入
    # 可以在这里加入更多动态内容，如检索到的知识片段、 todo 列表等
])

在这个示例中，ConversationBufferMemory 用于存储和检索对话历史。 ChatPromptTemplate 允许我们构建一个结构化的提示，其中 MessagesPlaceholder 用于在运行时插入对话历史。系统消息被定义为相对固定的内容，这有助于提高 KV 缓存的命中率。用户输入和对话历史将作为变量动态注入到提示中。

5.2 定义工具与 Agent 逻辑

AI 代理的核心能力之一是调用工具。我们需要定义代理可以使用的工具，并构建代理的执行逻辑。在这个知识问答场景中，一个关键的工具是 「知识库搜索工具」 。

from langchain.agents import Tool, AgentExecutor, create_openai_tools_agent
from langchain.tools import tool

# 假设我们有一个简单的知识库搜索函数
# 在实际应用中，这里会连接到 Elasticsearch 、数据库或其他知识存储
@tool
def search_knowledge_base(query: str) -> str:
    """Searches the internal knowledge base for relevant information."""
    # 这里只是一个模拟，实际应返回检索到的知识片段
    print(f"Searching knowledge base for: {query}")
    # 模拟返回一些知识
    if "请假政策" in query:
        return "公司的请假政策规定，员工每年享有 15 天带薪年假。"
    elif "报销流程" in query:
        return "员工报销需先在系统中提交报销单，然后打印出来由部门经理签字，最后交至财务部。"
    else:
        return "未找到相关信息。"

# 将工具封装成 LangChain 的 Tool 对象
tools = [Tool(name="KnowledgeBaseSearch", func=search_knowledge_base, description="Useful for searching internal company policies and procedures.")]

# 使用 LangChain 的 create_openai_tools_agent 创建代理
agent = create_openai_tools_agent(llm, tools, prompt)

# 创建 AgentExecutor 来运行代理
agent_executor = AgentExecutor(agent=agent, tools=tools, memory=memory, verbose=True)

这里，我们定义了一个名为 search_knowledge_base 的工具函数，并使用 @tool 装饰器将其封装成 LangChain 的 Tool 对象。这个工具接收一个查询字符串，并返回相关的知识片段。在实际应用中，这个函数会连接到真正的知识库 （如 Elasticsearch） 进行检索。然后，我们使用 create_openai_tools_agent 函数，结合之前初始化的 LLM 、工具列表和提示模板来创建代理。 AgentExecutor 则负责实际运行代理，它会处理与模型的交互、工具调用以及记忆更新。

5.3 实现上下文管理与交互循环

最后，我们需要实现一个交互循环，允许用户与 AI 代理进行多轮对话。在每一轮对话中，代理会根据当前的用户输入、对话历史和可用的工具来决定下一步行动。

# 模拟用户交互
def chat_with_agent(user_input):
    response = agent_executor.invoke({"user_input": user_input})
    return response["output"]

# 示例对话
print(chat_with_agent("请问公司的年假政策是怎样的？"))
# 预期代理会调用 KnowledgeBaseSearch 工具，并返回相关信息

print(chat_with_agent("那病假呢？"))
# 预期代理能根据上下文理解"病假"是上一个关于"假期"话题的延续，并尝试搜索病假政策
# 如果知识库中没有病假信息，可能会回答未找到或引导用户询问更具体的问题

# 可以在这里加入更复杂的逻辑，比如更新 todo 列表、处理错误等
# 例如，如果工具调用失败，可以将错误信息记录并反馈给模型
# 或者，根据任务复杂度，动态调整 prompt 中的指令

在这个交互循环中，agent_executor.invoke()方法接收用户输入，并结合记忆中的对话历史，生成完整的提示给 LLM 。 LLM 会根据提示决定是直接回答问题，还是调用某个工具。如果调用工具，AgentExecutor 会执行工具函数，并将工具的输出再次提供给 LLM，由 LLM 整合信息后生成最终回复。这个过程会不断重复，实现多轮对话。通过精心设计提示模板、工具定义和记忆管理，可以有效地将 Manus 的上下文工程经验融入到这个基于 Python 和 LangChain 的 AI 代理中。例如，可以在 prompt 中加入一个 todo_list 的占位符，并在每次迭代中根据模型输出和工具执行结果更新这个列表，从而引导模型的注意力。

6. 总结与展望

将 Manus 在上下文工程方面的宝贵经验应用于企业级 AI 代理的构建，特别是以 Python 技术栈为基础的企业内部知识问答系统，能够显著提升系统的性能、可靠性和用户体验。这些经验教训不仅为 AI 代理的设计和开发提供了具体的指导原则，也为应对当前 AI 技术面临的挑战提供了有效的解决思路。

6.1 应用 Manus 经验带来的系统性能提升

通过系统性地应用 Manus 的核心经验，企业知识问答系统可以在多个方面实现显著的性能提升。首先，优化 KV 缓存命中率的策略，如保持提示稳定和采用追加式上下文，能够大幅降低 LLM 的推理延迟和 API 调用成本，这对于高并发、大规模应用的企业环境尤为重要。其次，上下文感知的工具调用与状态管理使得 AI 代理能够更智能地选择和利用外部工具，避免了无效调用和资源浪费，提高了任务执行的效率和准确性。第三，利用外部记忆 （如 Elasticsearch） 构建知识库，并通过 RAG 技术增强模型能力，使得系统能够基于企业最新的、特定的知识进行回答，克服了 LLM 知识截止和通用性过强的问题，提升了答案的相关性和专业性。第四，通过动态 todo 列表引导模型注意力，有助于 AI 代理在处理复杂、多步骤查询时保持专注，避免偏离主题，提高了处理复杂任务的能力。第五，完善的错误处理与反馈机制，以及提供丰富多样的示例数据，能够增强 AI 代理的鲁棒性和适应性，使其能够从错误中学习并持续改进，更好地应对各种用户输入和业务场景。综合来看，这些经验的运用，使得企业知识问答系统能够更高效、更智能、更可靠地为员工提供信息支持。

6.2 企业级 AI 代理的未来发展方向

展望未来，企业级 AI 代理的发展将更加注重深度与特定业务流程的融合、更强的自主学习和适应能力、以及更高级别的安全与合规性。首先，AI 代理将不再仅仅是信息查询的工具，而是会深度嵌入到企业的各个业务流程中，成为员工日常工作的重要助手和决策支持系统。例如，AI 代理可以主动监控业务流程状态，预警潜在风险，甚至自主执行一些常规性、重复性的任务。其次，未来的 AI 代理需要具备更强的自主学习能力，能够从与用户的持续交互中、从企业不断积累的数据中主动学习和提炼知识，不断优化自身的行为策略，而不仅仅依赖于人工设计的提示和规则。这包括更高级的自我修正机制、基于用户反馈的持续优化以及对新知识的快速吸收和整合。第三，随着 AI 代理在企业中应用范围的扩大和深度的增加，数据安全、隐私保护和合规性将成为更加突出的问题。未来的企业级 AI 代理需要内置更强大的安全机制，确保数据的全生命周期安全，并满足日益严格的行业监管要求。此外，可解释性也将是重要的发展方向，AI 代理需要能够清晰地向用户解释其决策过程和答案来源，以建立用户信任并方便问题追溯。最后，随着多模态大模型的发展，未来的企业 AI 代理将能够处理和生成文本、图像、语音等多种类型的信息，提供更加丰富和自然的交互体验，从而在更广泛的场景中赋能企业运营。

发表评论