智能体成熟度模型：人工干预监督、工具工程、协调机制。
在实际应用中测试了五种智能体成熟度等级：人工干预监督、工具工程、多智能体协调，以及仍未解决的问题。
来源: Agentic Architectures — Article 15: The Maturity Model Revisited
代理成熟度模型看似容易绘制，实则难以真正应用。在纸上它显得十分清晰：从简单的工具调用者开始，最终发展为能够自我改进的生产系统。在有人尝试在负载环境下运行这些框架之前，它们总是看起来井井有条。但一旦有了实际代码，同一个模型呈现出的面貌就大不相同了。这并非模型本身有误，只是理论上的认知与实际生产环境中的认知属于不同类型的知识。地图无法告诉你凌晨三点时道路的实际情况——那时断路器无法闭合，而值班轮班的人正是你自己。
这是在相关层次真正构建完成之后对该模型的回顾：各层次与工程工作的对应关系、哪些理念在投入实际应用后不再适用、分层参考架构的具体形态，以及尚未解决的问题。此处的代码量极少，目的是退一步来审视整个技术架构。
五个层次，层层递进
该成熟度模型描述了智能体能力的五个层次。每个层次不仅仅是下层版本的强化版，因为它还依赖于下层的所有要素。无法跳过任何步骤——没有评估基础设施，智能体就无法实现可靠的自主运行；没有记忆功能，它也无法自我提升。这些层次是相互叠加的。
以下是各工程主题与这些层次的对应关系：
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
形态比映射更为重要。第五层级——自我提升——并没有专门的组成部分，因为它并非可以直接构建的东西。它是当记忆与评估功能协同作用时才出现的，即便如此，这一领域也尚未完全形成。该模型的顶层仍然带有某种理想化的色彩。自我提升在今天可以近似实现，但还无法完全达成。
在最初构思该模型时，这一点并不明显。第五层级看起来像是通过组合合适的组件就能达到的目标。但实际上，它更像是一个随着你不断接近而愈发遥远的地平线。
从人工干预到自动化协调：生产过程所修正的观念
这是框架文档永远无法捕捉到的部分，因为它只能通过实际构建才能形成。最初的几个假设被证明是错误的，或者至少是不完整的。
记忆功能被严重低估了。在最初的构想中，记忆仅被视为一个功能点，作用是让智能体行为更具连贯性。但进一步研究后发现，记忆实际上属于基础设施范畴，涵盖了所有相关要素：架构设计、检索质量、衰减机制以及租户隔离。随后还有一个更令人不安的发现——即便我们懂得构建的那些基础设施，也并非最恰当的抽象形式。由于没有专为记忆设计的解决方案，团队们只能使用原本为其他用途设计的数据库。在最初的模型中，记忆是最被忽视的要素。
核心目标是可预测性，自主性则是次要的。这是最根本的转变。早期，人们通过智能体在无人干预下能完成多少任务来衡量其进步，因此任何新增的独立性都被视为发展。然而，那些独自行动却不可预测的智能体只会更快造成危害。在所有重要的应用场景中，受监督下的可靠性比单纯的独立性更为重要。有一个典型的失败案例：某个智能体自主创建了数十张重复工单。生产系统需要的是适度且可控的自主性——这种自主性应当有界限、可审计、可预测，且那些需要人类决策且后果严重的情况应由人类来处理。曾有读者认为，系统编排应追求可预测性而非自主性，这一观点过了很长时间才被接受。
安全性是每一层的固有属性。最初的方案将安全性视为接近结尾的部分，认为在系统运行后再加以处理即可。注入攻击纠正了这一做法。它的攻击目标在别处：工具被调用的地方、内存写入的路径、目标修订的方式，以及智能体之间的通信。每个组件都具有安全维度。在工具边界进行身份验证、在内存中实现隔离以及对目标修订进行控制，这些都是分散在系统各处的安全措施，而非集中在某个单一环节。
循环比提示语更重要。这一内容放在最后，其实本应最先介绍才更实用。当前这个领域的大量精力都投入在提示语设计以及寻找“神奇”的表述上。但智能体并非提示语，而是一个通过多步操作来追求目标的循环结构；即便有完美的提示语，若置于有缺陷的循环中，也只能造就出一个虽表达流畅却永远无法达成目标的智能体。一旦学会用循环的思维方式，许多看似模型局限的问题其实都是循环设计上的缺陷。
让人类参与其中并非可以通过技术手段消除的缺陷。人们很容易认为，随着技术的发展，人类干预只是暂时性的辅助手段，日后应当被取代。最优秀的生产智能体系统并非那些最具备自主性的系统，而是那些将人类判断力精确地置于所需之处、而不出现在其他地方的系统。人类监督并非某个阶段过后就会结束的东西，而是任何那些错误会带来实际代价的系统所必然具备的、持续存在的特性。
整体架构一览
将上述所有要素整合起来，一个成熟的智能体系统就呈现为这样的结构：
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
这些垂直层次构成了请求路径。任务在人工监督下进入系统，通过目标与循环机制被塑造，由多个组件协同处理，通过工具框架得到优化，最终在模型上执行。贯穿整个系统的各种问题会影响到每一层。内存既为循环机制提供支持，也为工具框架服务。安全机制负责保护工具边界并管控目标修订。成本因素则决定了每一步的模型选择。部署环节则将所有这些元素整合在一起。
这种逐层查看的方式会掩盖这些组件之间紧密交织的关系。某一处的变化会波及到其他部分。如果不了解循环机制，就无法优化成本，因为高昂的运行成本往往源于无法终止的循环。安全工作同样需要关注内存问题，因为一旦有数据条目被破坏，它仍会持续造成影响。应将这些层次视为一个相互关联的整体，而非独立的模块集合。
尚未有人解决的问题
这可能是最有用的部分，因为前面的内容都在描述已经可以实现的功能，而这一部分则说明了目前还无法实现的内容。一张真实的边界图谱比经过修饰的图谱更有价值。
真正的智能体原生内存并不存在。目前的记忆系统都是基于为其他目的而构建的数据库和向量存储构成的。据估计，要实现一个真正能够记录时间、通过关联检索信息、有意识地遗忘数据，并由智能体自行决定存储内容的系统，还需要几年的时间。现有的方案虽然能发挥作用，但并不符合实际需求。
智能体无法准确判断其知识何时适用。这正是陈旧记忆问题的更深层表现。智能体可能会检索到相关的程序，并自信地将其应用于不合适的场景，因为很难明确界定某条知识何时不再有效，而在检索到相关内容后进行测试更是困难。在一个领域有效的程序在另一个领域可能会被错误应用，而智能体往往以及用户通常都不会察觉到这一点。这是一种根本性的限制，而不仅仅是技术上的缺陷。
自我评估并不可靠。升级逻辑与置信度评分都依赖于智能体准确判断自身的确定性。有时它能做到这一点，但有时也会在看似确信的情况下出错，这是最有害的情况，因为它会破坏所有依赖智能体认识自身局限性的安全机制。目前尚无可靠的自我评估校准方法。
工具包无法在模型之间迁移。每个工具包都是针对特定模型的行为进行调优的。更换模型后就需要重新调整提示词、循环检测阈值以及验证标准。从原理上讲本不必如此，但至今还没有人能构建出能在模型更换时无需调整就能正常使用的工具包抽象层。模型升级仍然属于项目范畴，而非简单的配置更改。
并不存在真正的持续学习。程序记忆只能近似实现学习效果：成功的解决方案会被存储并重复使用。但权重并不会改变，智能体也无法从经验中发展出新的能力。它只是建立了一个过去解决方案的库并从中调取内容。目前的生产系统还无法实现那种真正能通过经验在某一类问题上不断进步的智能体。
边际成本难以预测。虽然存在成本管理工具且确实有效，但数据分布的尾部情况十分棘手。那小部分陷入病态循环或遇到特殊边缘情况的运行，仍会以难以预见的方式消耗大量资源。虽然可以设定成本上限，但却无法始终预测成本数值。
这些都不是阻碍前进的理由。这些都是当前技术框架的边界，了解它们的位置正是将工程实践与空想区分开来的关键。
从何处开始：在代理协调之前先完善工程基础
如果你正在构建代理系统，不要把这些要素当作构建顺序来处理。它们是按概念分类的，而非按构建顺序排列的。如果按照那种顺序构建，你会在还没有可用工具来管理内存时就先创建了内存，在还没有需要评估的内容时就先进行了评估。
应从你的系统在成熟度阶梯上的当前位置开始着手。
- 那些不可靠的基本工具调用代理，应该先从工程基础建设入手，因为大多数可靠性问题都出在这里。
- 那些已经发展到瓶颈的单一代理，则已经具备进行多代理协调的条件。
工具可以互换，但理念不可替代
本次讨论中的示例是基于AWS Bedrock、LangGraph和LangChain构建的。这些选择是出于实际应用需求，因为它们正是当前生产环境中所使用的技术栈，但它们并非唯一的正确方案。大多数关键因素都与这些技术栈并无直接关联。在任何云平台上，身份认证都应设置在工具边界处。在各类框架中，循环机制比提示词更为重要。内存层次结构、多智能体协作模式、攻击类型以及人工监控下的成本与可逆性矩阵等概念，都能应用到其他技术栈中。
这也正是为什么拥有基于 Ollama 和 Docker 的本地替代方案很有价值的缘故。它能让这些模式在无需支付云服务费用的情况下运行，同时也证明了相关概念与实现方式是可以分离的。如果某种内存架构能在本地模型和本地向量存储上运行，那么这种设计从一开始就与 Bedrock 毫无关联。它所解决的是根本问题，而这个问题在任何平台上表现都类似。调度模式也是如此，因为用另一个框架替换 LangGraph 只会改变循环的语法，却不会改变其需要应对的故障模式；同样，评估工具也可以指向背后的任意模型。
将其写下来后所揭示的内容
向那些没有经历过你学习过程的人，按顺序清晰地解释某个主题，反而能暴露出你自身理解上的漏洞。很多主题在试图将其写下来之前，都让人觉得已经完全掌握了。
这个领域的真实状况是：它既充满机遇又尚不成熟。如今有许多两年前还无法实现的事情，人们很容易自欺欺人，因为流利的表达会让人误以为自己具备实际能力。那些演示效果出色的模型与能在实际环境中稳定运行的模型之间存在着巨大差距，而大部分复杂的工程工作都集中在这一差距之中。
如果有一条信息值得传回起点，那就是有趣的工作并非在于让智能体变得更强大。模型本身已经十分强大，并且会以你无法掌控的节奏持续改进。真正有意义的工作是让这些强大的模型变得可靠、可预测、安全，同时价格合理到足以让人放心将其用于实际决策。这是工程学，而非魔法：通过控制结构、循环、内存、评估以及所有那些虽不那么光鲜但能将具备能力的模型转化为可依赖之物的基础设施来实现目标。
智能来自模型，而架构则需由你自己构建。
相关阅读
- 实用笔记：代理架构，第12篇：我们为它做好准备了吗：针对《实用笔记：代理架构，第12篇：我们为它做好准备了吗》中的内容提供的操作指南，包括适用于采用该架构的团队的契约、检查项以及可直接插入的代码模板。
- AI代理中的人机协同模式：审批关卡、升级机制与审计追踪：当代理需要人工确认时，文中介绍了四种相关模式（审批关卡、升级处理、协同编辑、抽样机制），以及如何使用LangGraph实现暂停与恢复功能、设置超时时间、记录审计日志，并指出了相关注意事项。