为什么更智能的智能体架构并不总能提升效果
我对智能体将给知识工作带来的影响依然持乐观态度。正如我在之前的文章中所指出的，那些由明确规则和成熟系统塑造的领域（包括会计和合同管理）已经看起来非常适合这种自动化。但即使机遇真实存在，现实情况是，AI团队仍在学习如何构建能在生产环境中可靠运行的智能体。将一个脆弱的原型转变为可靠的系统，需要的不仅仅是一个好的提示词。这意味着要仔细思考底层架构。为了看清这些系统是如何构建的，将其技术栈分解为主要部分是很有帮助的。
在一个可运行的AI智能体系统中，三个核心组件定义了其能力和行为：
- 工具 是智能体可以执行的单个操作：数据库查询、API调用、文件操作或代码执行。它们是使智能体能够触及并交互外部系统的原子操作。
- 技能 处于更高层次。它们是可重用的工作流，将多个工具与特定的推理步骤相结合，以完成有意义的业务目标，例如分析合同或对支持工单进行分类。
- 上下文文件（如
AGENTS.md）的工作方式不同。它们不增加能力，而是定义智能体应如何思考和行为。它们指定智能体的角色、决策指导原则、约束以及面对选择时应用的推理模式。
这种三层分离很实用：它允许你将工具组合成不同的技能，并在不同的行为框架下运行这些技能，而无需重建核心逻辑。
生产级智能体系统还依赖于其他几个与工具本身同样重要的组件。内存系统 维持跨多轮交互的连续性，允许智能体引用过去的决策和上下文。编排框架 决定应由一个智能体还是多个专用智能体来处理任务。规划模块 帮助将复杂目标分解为可执行的步骤序列。状态管理 确保上下文在交互间得以延续。护栏和权限 防止滥用并执行组织策略。监控和日志记录 让你看到智能体的实际行为——这往往与你预期的不符。这些部分协同工作。没有内存，智能体无法保持上下文。没有编排，它无法协调复杂工作。没有护栏，它可能违反政策。
重新思考智能体系统中的协调与内存
在所有这类工具类别中，仍有大量实验正在进行。编排是一个活动密集的领域，因为构建者意识到早期框架往往过于僵化。较旧的系统迫使开发者预先规划每个工作流，或依赖无结构的智能体聊天。新工具正在通过提供更大的灵活性和控制力来填补这一空白。Cord 是一个最近的例子，它允许智能体动态构建自己的任务树。它让模型能够决定何时将工作分解为并行轨道或共享上下文，而无需硬编码计划。Emdash 从工作空间角度解决编排问题，允许开发者在隔离环境中并行运行多个编码智能体。这消除了同时管理不同终端和等待单个模型完成工作的混乱现实。
添加智能体的一个未被充分认识的成本是协调开销。在多对多设计中，随着智能体数量的增长，这种开销会迅速上升。集中式编排可以减少部分复杂性，但它也会引入自身的瓶颈。更多的智能体也意味着更多的推理成本和更多累积错误的机会。最近的研究表明，添加智能体在某些情况下（尤其是工作可以清晰分解时）会有所帮助，但当单智能体基线已经很强或任务高度顺序化时，它也可能增加开销甚至降低性能。
内存和上下文系统也在发展，以处理不仅仅是对话历史。正如我在之前的一篇文章中所论述的，大多数当前的内存方法更擅长检索事实或保存对话，而不是帮助智能体可靠地重复操作工作。为了解决这个问题，开发者正在转向操作技能存储库或上下文文件系统。这更多是关于程序性记忆，而非聊天记录。这些新系统不是用无穷无尽的文档来超载提示词，而是将成功的工作流保存为永久性程序。智能体只加载处理当前特定任务所需的具体指令。这种方法将临时的问题解决转变为可靠的公司资产，同时大幅降低计算成本。
从艺术走向工程：智能体设计的工程化
随着团队采用新的内存和编排工具，他们往往在测试这些方法是否真正有助于自身环境之前，就继承了所谓的“最佳实践”。AGENTS.md 就是一个很好的例子。这些简单的仓库级文件旨在指导编码智能体在代码库中的行为方式。最近一项研究通过在标准基准测试和一个基于真实代码库构建的新基准测试 AGENTBENCH 上测试编码智能体，检验了这些文件是否兑现了承诺。结果并不特别令人鼓舞。自动生成的上下文文件降低了任务成功率，同时增加了超过20%的推理成本。智能体确实遵循了指令并更广泛地探索了代码，但这种额外的活动并没有转化为更好的结果。即使是开发者编写的文件也仅带来了微小的提升。
构建AI智能体是一门工程学科，而不是艺术形式。你得到什么，取决于你测量什么。
太多团队仍然在构建一个工作流，运行几次，凭感觉认为没问题，然后就发布。这种方法带来了真正的风险。机器学习领域的标准做法长期以来一直是在添加每个新组件之前进行测试：这真的能改善结果吗？它现在会在哪里失败？同样的逻辑也适用于智能体系统。从 AGENTS.md 的研究中得到的教训并不是上下文文件毫无用处。而是添加任何组件——无论是指导文件、新智能体还是提示词更改——都应被视为一项工程决策，而不是默认操作。Leo Meyerovich 很好地阐述了这一点：团队得到他们测量的东西。在实践中，这意味着为你的特定用例定义清晰的评估标准，并且只保留那些能改善结果的部分，无论指标是任务成功率、速度、安全性还是成本。在智能体系统中，问题不在于某个建议听起来是否合理，而在于它是否能在你的环境中提升性能。
将AI智能体投入生产意味着协调一个由工具、技能、编排框架、内存系统和护栏组成的技术栈。开发者和初创公司仍在快速迭代这一基础设施（通常是在开源领域），这种实验正在帮助该领域走向成熟。但人们也容易将架构的复杂性误认为是进步。正如关于上下文文件的证据所表明的，结合了严格评估的更简单工具，往往会击败未经实际工作测试的更复杂设置。问题的部分原因在于，一个可运行的智能体系统中的变量数量比最初看起来要多。分块策略、嵌入选择、检索方法、提示结构、上下文窗口大小和模型选择都会相互作用。依赖默认设置和直觉来管理这些变量的团队，实际上是在猜测。系统性的评估不一定意味着要测试每一种组合——但它确实意味着要了解哪些变量对你的特定用例最重要。
让智能体为生产做好准备意味着运行计算密集型实验来找到正确的配置。拥有一个能让你高效运行这些实验的AI平台是一个显著优势。Dean Wampler 最近在一篇关于 PARK 技术栈（一个基于 PyTorch、AI模型与智能体、Ray 和 Kubernetes 的开源基础）的新文章中探讨了这一点。最终，拥有可扩展基础设施和严格评估的团队将能更好地解决真实的业务问题。
如何将 LanceDB 集成到个人自主智能体中 — 基于 LanceDB + OpenClaw 集成指南
*（本文内容来自 “A Practitioner’s Guide to GTC 2026”）*FINISHED
