1. 两朵乌云的名字变了，但天空还是那片天空
每次提到“两朵乌云”，懂行的人都会心一笑：一百多年前的那两朵，后来长出了相对论和量子力学，直接把物理学改写了。我最近一直在想一个问题——今天的智能体领域，头顶是不是也悬着两朵乌云？
先说我的判断：第一朵，是大模型推理能力的“不可靠”。你让一个模型做单点知识问答，它表现神勇；可一旦把它架到智能体里，让它承担一连串的决策动作，它就会在某个不起眼的环节犯一个极其愚蠢的错误，然后一路错到底。更麻烦的是，你往往要等执行完才知道它错了，这种“延迟暴露”的不可靠，比错误本身更致命。
第二朵，是智能体自主性的“不完备”。现在的绝大多数智能体，本质上是套了提示词的“对话接口 + 工具调用器”。它没有真正的目标感，拆解任务时靠的是LLM即兴发挥，遇到预期外的反馈就懵，更不用说“用上一次失败的经验改进下一次决策”这种最基本的闭环能力——它在架构层面就没有这根筋。
我这句话可能有点得罪人，但确实是这样：我们造了很多看起来很聪明的智能体，但把它们扔到一个需要连续决策、不可逆操作、自我纠错的真实场景里，暴露出来的短板恰恰不是“模型不够大”，而是架构本身缺零件。所以，当我们说“最小完备架构可能是关键”的时候，我说的不是某个具体产品、某个框架名，而是这么一个方向：用最少的结构组件，把智能体从“会聊天、会调工具”升级成“能闭环、能纠错、能自评估”的完整系统。
这篇文章我不想写概念综述，就想把我最近的调研、实验和思考摊开来讲。如果你也在做智能体、或者正在为一个总是“差一口气”的自动化系统头疼，这篇东西应该对你有用。
1.1 为什么我用“乌云”来比喻这两个问题
因为这两个问题都符合“乌云”的三个特征：第一，它们笼罩的范围极广，不管你是做客服智能体、代码生成智能体还是科研辅助智能体，迟早会被这两块云淋到雨；第二，它们不是靠修修补补就能绕开的，必须从系统层面重新设计；第三，也是最关键的——历史上能吹散乌云的，从来不是更好的望远镜，而是全新的理论框架。
现在做智能体的人，大部分精力花在“给模型加工具”“给提示词加约束”“给流程加规则”这三件事上。这些努力都有价值，但都没触到根子。你给一个没有血液循环系统的人穿上再好的衣服，他还是跑不了马拉松。同样的道理，一个推理不可靠、又缺乏自主闭环能力的系统，你给它接再多API，它本质上还是一个“放大版的聊天框”。
所以我想往后退一步，问一个更基础的问题：如果剥离掉所有花哨的功能，一个智能体要实现稳健的自主工作，最低限度需要哪几个零件？这些零件怎么接起来，才能让系统具备“自己发现自己错了、自己修正自己、自己判断什么时候该停”的能力？这就是我理解中“最小完备架构”要回答的问题。
2. 先给两朵乌云画个像：它们到底是怎么毁掉一个智能体的
聊架构之前，我得先把病根讲清楚。不然你可能会觉得“最小完备”是个玄学概念——其实它是在对着两个非常具体的病灶开刀。
2.1 第一朵乌云：推理链条越长，错误率越是指数级膨胀
有个现象你应该不陌生：一个五步以内的任务，大模型智能体完成得像模像样；一个二十步的任务，成功率断崖式下跌。原因很简单——大模型的每一步推理都有一定的错误概率，而这些错误不是均匀分布的，在需要精确计算、严谨逻辑、状态追踪的步骤上，错误率会骤然升高。
做一个粗略的估算你就明白了：假设每一步决策的成功率高达95%，一个十步的连续任务，整体成功率是多少？0.95的10次方，大约59.9%。看着还行对吧？但如果是二十步呢？0.95的20次方，大约35.8%。三四十步的复杂任务呢？直接掉到12%以下。这不是耸人听闻，这是数学规律。而真实世界的任务，拆解下来往往远超十步。
更可怕的是，这种错误不像代码报错那样有明确的异常信号。大模型犯错的时候，它往往表现得无比自信。它会用一种斩钉截铁的语气告诉你一个错误的中间结论，然后基于这个结论继续往后推，直到最终结果一塌糊涂。这就是我反复强调的“延迟暴露”问题——你没有在错误发生时收到警报，而是要在整个任务跑完之后，对着一个荒谬的最终输出，去倒查是哪个环节污染的。
用生活类比理解：这就像一个厨师做一道二十道工序的菜，每道工序他都有5%的概率把调料放错。他做的时候不尝、不检查、不回看菜谱，等菜端上桌才发现是甜的。你骂他也没用，因为问题不在某一刀某一步，而在于整条流水线没有“质检点”。
2.2 第二朵乌云：没有反射弧的智能体，本质上是个开环系统
第二朵乌云更隐蔽。你看现在很多智能体Demo，能连数据库、能调API、能写代码，看起来很全能。但你往深处看，它的工作方式是线性的：你给一个目标——它生成一段计划——按计划逐步调工具——拿到结果——输出。一旦某一个工具返回的结果跟预期不符，或者环境状态发生了变化，它该怎么办？大多数系统的答案是：硬着头皮往下走，或者干脆死循环重试。
这就是开环系统的问题：它缺少一个“感知-比较-修正”的闭环。生物学里有个概念叫反射弧，感受器接收刺激，传入神经送到中枢，中枢判断后经传出神经命令效应器行动。现在的智能体，前面半截（感受器和传入神经）是有的，中间的中枢判断是弱的，最后那半截（根据结果返回去修正动作）几乎是不存在的。
什么叫“完备”？我心里它指的是：这个系统即使在没有人盯着的情况下，也能像一个有经验的员工那样，在遇到异常时停下来、做判断、调方案、再上路；在连续多次异常时知道自己不行了，而不是像个无头苍蝇一样反复重试。
打个比方，你让一个实习生去整理一份Excel报表，他做错了格式，你告诉他要修正——这不叫完备。完备是：他交给你之前，自己已经有一套检查机制，能发现“这行数据跟源表对不上”“这一列合并出错了”，并且知道用什么标准来判断对错。当前多数智能体缺的就是这套“自己检查自己”的机制。
2.3 两朵乌云其实是相互强化的
分开看是两朵，合起来就是一场风暴。推理不可靠，导致闭环机制里的“判断”本身就不可靠；而因为缺乏闭环，推理错误又无法被及时发现和纠正。这就像一个视力不好的人，开车的时候方向盘还有虚位——你说不清是看不清路导致的偏航，还是方向盘本身的问题，总之就是很难稳稳当当地开到目的地。
我见过太多团队把精力花在优化单个模型的推理能力上，指望换一个更大的模型就能解决所有问题。模型确实在变强，但只要这个“开环 + 不可靠”的底层结构不变，你换再大的模型，它也只是更聪明地犯错、更流畅地跑偏而已。
3. 为什么我不看好靠“堆模型”和“堆数据”吹散乌云
往上看了一眼标题：“最小完备架构可能是关键”。这里有个隐藏的判断题——为什么答案是架构，而不是别的什么？
3.1 模型的进步解决不了“系统性”问题
这两年大模型的进步速度有目共睹，推理能力、代码能力、工具使用能力都在往上走。但你要注意，这些进步解决的是“单点智力”问题。可智能体的核心问题恰恰不是单点智力，而是系统可靠性。
举一个很直白的例子：就算你把模型能力提升到每一步错误率降到1%，一个三十步的任务成功率也就73.7%。距离“可靠”还差得远。靠堆参数把错误率压到0.1%？三十步任务成功率95.8%，确实不错了——但代价是训练和推理成本可能增长百倍，而且这还是没有考虑环境不确定性的理想情况。真实场景里任务不是一条直线，它会分叉，会有环境反馈，会有随机扰动。在这种情况下，即使每一步的失误率极低，系统的成功率依然会随着任务复杂度的上升而瓦解。
我的观点很明确：靠模型自身能力提升去硬扛任务复杂度，是一条成本极高且不可持续的路径。
3.2 数据是药，不是饭
也有人说，可以用更多高质量数据来训练，让模型学会“在复杂任务里不犯错”。数据确实有用，但它是药，不是饭。药是用来治病的，你不能拿药当主食吃。
原因有两层。第一，覆盖复杂决策链的数据极难获取，你很难找到大量“三十步以上、中间有干扰、需要纠错、有真实反馈”的现成轨迹数据；第二，模型的泛化能力是有边界的，靠数据喂出来的行为，在遇到分布外的新场景时依然会失效。真实世界的任务是不可能被数据提前穷举的。
所以，与其把宝全部押在模型本身，不如做一个更工程化的选择：接受模型会犯错这个事实，然后在架构层面设计一套“容错-纠错-自愈”的机制。
3.3 从另一个领域借来的直觉
我看过很多知识分享中提到过类似的观点，但真正让我下定决心的，是一次技术讨论里一位朋友说的：“功能可以少，菜可以简陋，但你得有一个能自我维持的闭环。”这个想法和生物学里“单细胞就是最小完备生命”的论断很像。单细胞生物没有复杂的器官，但它有完整的代谢闭环、应激反应、自我复制能力，所以它能独立生存。
智能体也一样。你现在给它配一百个功能插件，不如先确认一件事：它有没有一个最小的自我维持环——感知、决策、行动、反馈、修正——如果这个环闭合了，功能慢慢加，它会越用越聪明；如果这个环是断的，你加再多功能也只是在断桥上盖房子。
而且，这种“先闭环，再扩充”的思路还有个额外的好处：维护成本低。架构简单意味着每一环都能被清晰地审视和测试，出问题了一查就知道是哪一段断了。很多人不愿意重构系统，不是因为现有系统多好用，而是因为它已经长成了一团谁也理不清的乱麻。最小完备架构给你一个可以推倒重来的基准线。
4. 最小完备架构的五部件：一个都不能少
聊完了“为什么”，终于到“是什么”了。基于我对多个智能体项目的复盘和自身的实验，我总结出五个最核心的组成部件。这个列表不一定权威，但它们是构成“闭环”所必需的，缺了任何一个，系统都会退化成一个没那么智能的开环工具。
4.1 感知接口：把环境变数变成系统内部变量
感知接口解决的是“系统怎么知道外面发生了什么”的问题。不要觉得这是废话——你现在去检查市面上的智能体，很多所谓“感知”就是直接把用户的输入文本丢给LLM，工具返回的原始JSON它也丢给LLM。这根本不能叫感知。
真正的感知接口至少要做三件事：第一，归一化，把不同来源的异构信息（文本、API返回、文件内容、传感器数据）转成统一的结构化格式；第二，过滤，把无关噪声、错误数据、矛盾信息剔除掉，避免垃圾进垃圾出；第三，标注置信度，告诉上层“这个信息的可信度有多少”。
做一个真实的项目你就知道感知接口的价值了。我做个客服智能体时，用户传来的截图里有表格、有聊天记录、有时间戳，五花八门。如果我把这些原始图片直接丢给模型去理解，它经常读漏关键信息。后来我在最前面加了一层“结构化抽取器”，先把图片转成标准字段，比如“订单号、状态、问题描述、用户期望”，模型再基于结构化字段工作，准确率提升明显。
这个经验教训是：不要让主模型去做它不擅长的事。主模型的注意力应该集中在推理和决策上，而不是反复解读混乱的原始数据。感知接口把“看”的工作做了，主模型才能专心“想”。
4.2 认知中枢：推理、规划与决策的统一场所
第二个部件是认知中枢，也就是智能体里负责“想”的部分。它承担三个职责：把目标拆解成可执行的子任务、为每个子任务选择动作、在多个可能方案之间做权衡。
这里有一个常见的认知误区：很多人以为目标拆解就是写一段“请按以下步骤执行”的提示词。但实际上，一个好的认知中枢必须做到“动态规划”——它不应该在任务开始时就一次性生成所有步骤，然后机械执行；它应该只做当前阶段可见范围内的规划，每执行一步，根据新的反馈重新校准后续计划。
用爬山来类比：你爬一座没走过的山，不可能在山脚就看全整条路线。聪明做法是走到一个平台，观察一下地形，再确定下一段怎么走。认知中枢也该如此——它的规划周期应该短于任务的复杂度，而不是试图一次规划到底。
这种能力靠什么实现？我的经验是，把“计划”和“执行”分开来跑。让一个模块负责产出高层计划（高层目标分解成里程碑），另一个模块负责当前里程碑的执行细节。两个模块用结构化的中间表示来通信（比如JSON格式的任务描述、状态、完成标准），不要用长篇自然语言来回聊天，那样既费token又容易丢失信息。
4.3 行动接口：把决策翻译成世界能懂的命令
行动接口解决的是“怎么把想法变成动作”的问题。它往上是认知中枢，往下是各种工具和API，作用就是做翻译和适配。
这一段在工程上最常见的问题是：工具调用的参数格式不统一，而且失败模式千奇百怪。不同API的鉴权方式不同、超时时间不同、错误码不同、返回结构不同。如果你让主模型直接面对这一堆原生接口，它大概率会在某个奇怪的鉴权细节上翻车——这不是模型笨，这纯粹是接口设计不合理造成的负担。
行动接口应该做三层封装：第一层是统一协议，把工具调用的输入输出定义成标准格式，主模型只需要按统一格式传递参数，不需要知道HTTP细节；第二层是异常兜底，对常见的超时、限流、参数错误做预置处理，而不是把原始堆栈丢给模型让它自己“看着办”；第三层是语义化返回，把工具返回的原始内容翻译成对“任务进展”的描述，让上层能判断这一步到底成没成。
这一层设计好了，系统的主战场才不会打成一锅粥。我见过太多智能体项目死在“工具调用返回不可控”这种看似不起眼的问题上——某个外部接口偶尔返回一个空列表，主模型理解不了，就把它当成正常结果往下走，然后整个任务就被带偏了。行动接口就是要在这一层拦住这种“微小而致命的噪声”。
4.4 记忆系统：把经验变成可复用的资产
记忆系统是我的架构里最容易被人忽略、但我个人认为最不该被忽略的部分。市面上的智能体大多是“一任务一会话”，任务结束，记忆清空，下次任务又是从零开始。这和“好了伤疤忘了疼”有什么区别？
可行的做法是将记忆分三层。第一层是工作记忆，记录当前正在进行的任务状态——已经完成了哪些子步骤、下一步是什么、当前有哪些已知约束；第二层是情境记忆，按任务或项目维度保存上下文，任务中断后可以恢复；第三层是长期记忆，沉淀跨任务的经验和教训，比如“调用某类接口时容易超时，需要提前设置重试策略”“某类问题用A方案比B方案成功率高”。
长期记忆尤其有价值，因为它解决了我前面提到的“自我改进”问题。如果一个智能体每次遇到同样的问题都要从头开始踩坑，那它永远不可能变得“经验丰富”。有了长期记忆，它可以做到：遇到问题→解决问题→提取经验→存入记忆→下次遇到类似问题时直接调用。这个过程，才是真正意义上的“越用越聪明”。
实现上不必搞得太重。很多人一听到记忆系统就想到向量数据库、知识图谱、复杂索引，其实起步阶段你只需要一个简单的键值存储加一份良好的结构化记录文件就够了。重要的是有没有“沉淀”这个动作，而不是存储引擎多高级。
4.5 自评估器：给系统装上“质检员”
最后的这个部件，是整个最小完备架构的灵魂——自评估器。它回答的是“系统怎么知道自己做得对不对”这个问题。
直觉上你会觉得，让大模型自己评估自己不就行了吗？让它自己判断、自己反思，多简单。但实验下来，自我评估一个最大的陷阱是：模型会倾向于为自己的中途错误辩护。它会像一个自尊心很强的员工，宁可相信自己是合理的，也不愿承认“我中间那步算错了”。所以，自评估器不能和决策模块用同一个视角。
我比较推荐的做法是：自评估器使用独立的评估逻辑和评估指标体系。它不直接看“我的计划合理吗”这种开放问题，而是看一套具体的检查项——事实类检查：中间产生的结论有引用依据吗？数值类检查：计算结果跟原始数据对得上吗？完成度检查：任务的每一项验收标准都满足了吗？一致性检查：这个结论和前面的上下文有矛盾吗？
一个务实的小技巧：自评估器不应该是一个单独的LLM调用，而应该是一个“多策略组合”。简单的规则检查（字段非空、数值在合理区间）用代码实现，精确且零成本；复杂的语义检查（结论是否与用户意图一致）才调用LLM来做。用规则卡掉80%的低级错误，用LLM处理剩下20%的语义判断，这套组合拳的成本表现好得多。
这五部件合起来，才构成一个完整的闭环：感知输入→中枢推理→行动输出→反馈回传→自评估修正→更新记忆→下一轮感知。环路上的每一个节点都不复杂，但连成闭环后，系统的行为和开环架构完全不是一个物种。这就是“最小完备”中“完备”二字的底气所在。
5. 从理论到落地：怎么判断你的系统真的“闭环”了
结构讲完了，我知道很多人心里有个疑问：听起来很有道理，但我怎么把现在的系统改造过去？以及改造完之后，怎么证明它真的变强了？
5.1 改造第一步：先给现有系统装上“刹车”和“后视镜”
不要试图一口气把五个部件全部重构，工作量太大，风险也高。我建议按风险从低到高、收益从快到慢的顺序来。我自己带项目落地时的顺序是：
先加自评估器——它成本最低、见效最快。不需要动主干流程，只需要在任务的每个关键节点后面插一个检查点，让系统在执行下一步之前先确认当前结果是否合理。这相当于给车装上了刹车，防止一路狂奔冲向悬崖。
再加记忆系统——把每次任务的完整轨迹（目标、动作、结果、评估结论）存下来。初期只需要解决“能存能查”的问题，不需要很智能的检索。这相当于给了车一个后视镜，让司机能看到自己走过的路。有了轨迹数据，后续所有优化都会好做很多。
最后再重构感知接口和行动接口——这一步改动最大，但对体验的提升最根本。标准不统一导致的混乱一旦消除，后续的调试效率会成倍提升。如果你现在的系统混乱得已经无法修补，那可以先把这层重新整理一遍。
这套顺序背后的逻辑是：先确保不犯大错（自评估），再积累经验（记忆），最后才优化循环的效率和顺畅度（接口层）。认知中枢放在最后动，因为它的优化依赖前几层提供的高质量数据。
5.2 一个务实的验证实验：不能说“感觉变聪明了”
改造完之后，怎么证明有效而不是心理安慰？我建议不要看单次Demo的表现，要做一个“批量跑分”实验。具体做法是：准备一组复杂性递增的测试任务（我一般用10到30个不同类别的任务），旧系统跑一遍记录成功率，新系统跑一遍记录成功率，做对比。关键指标有三个：整体任务成功率（最终目标达成的比例）、平均纠错次数（每个任务中自评估器触发重新规划的频率）、无效动作比例（做了对最终目标没有贡献的Action的比例）。
我做过几轮这样的对照实验，结果非常典型：加了自评估器之后，纠错次数从0变成平均每任务2到3次，最开始你以为这是变差了——但无效动作比例明显下降、整体成功率从2成多涨到5成以上。这个规律很反直觉：一个从来不自我怀疑的系统，反而更容易在错误的路上狂奔；一个会中途停下来检查的系统，虽然看起来更“犹豫”，但这犹豫恰恰是它可靠的来源。
另外强烈建议记录“错误暴露延迟”——每次系统执行完任务之后，回查“第一个错误发生在第几步”。开环系统往往在第一步就错了，但直到最后一步才暴露；闭环系统通常能在两三步之内就发现问题并纠偏。这个指标比成功率更容易体感强烈地说明架构的价值。
5.3 别把架构搞成“伪闭环”
最后提醒一个我见得太多的失败模式——“伪闭环”。很多人看完这个架构觉得懂了，然后回到自己的系统里加了这么几个功能：提示词里加一句“请反思一下你的回答”、工具调用失败时让模型再试一次、任务结束时让模型写个总结。这不叫闭环，这叫仪式感。
真正的闭环有一个硬性标准：系统能够基于“对结果的评估”，产生“修改下一步行动”的具体输入。换句话说，自评估器的输出必须能反向影响认知中枢的决策，而不是仅仅生成一段“总结文字”放在那儿当摆设。如果你的反思提示词只是让模型输出了一段“我错了，下次要小心”的空话，但没有把这个“错”翻译成可操作的行动变更，那你的反思环节就还没真正接入回路。
判断闭环有没有接通，有个很简单的测试：把一个任务的中间某一步故意做错，然后观察系统能不能在不被你提示的情况下，自己发现异常并修正。如果它修订后的结果依然正确抵达最终目标，说明闭环是真的通了；如果它汇报了错误但行动没变，或者一路错到底，那就是伪闭环。
6. 这朵云也不是那么好吹散：挑战与第一个“经验累积点”
如果你看到这里，觉得“好，那我现在就去把最小完备架构搭起来”，我给你泼一盆冷水，但也给你指一条更具体一点的路。因为从我的亲身实践来看，这个方向上有三个高频踩坑点，先知道它们，你能少走至少一个月的弯路。
6.1 难点一：完备需要一个“可信的评估标准”，而这恰恰是最缺的
自评估器是整个闭环的支点，但它的建立依赖一套“什么是对的”的标准。在代码生成、数据处理这类有客观答案的任务里，标准好定义；但在开放式的创意任务、复杂的商务决策里，“正确”本身就有模糊性。你让自评估器去检查一个开放任务的结果，它会无所适从。
我的应对思路是：把“任务是否完成”拆成“可机械验证的硬指标”和“需要语义判断的软指标”两层。硬指标用规则和代码卡，比如数据完整性、格式合规性、约束条件满足度；软指标用LLM来评，且每次评估给出可解释的理由，让人类用户来决定采不采纳。先确保“错得离谱”的情况能被卡住，再慢慢优化软指标的精度。
6.2 难点二：加了自评估后，系统的总耗时和成本会上升
闭环的代价是“多走几步”——多一次评估调用、多一次修正循环。对于低延迟要求的场景（比如实时交互），这可能是个问题。
我的优化经验有三种：第一种是分级评估，简单任务走规则检查，只有复杂任务才启用LLM自评估；第二种是异步评估，把自评估放到不影响主流程的旁路上，避免阻塞；第三种是合并调用，把多次评估用结构化prompt合并成一次批量检查，减少往返。三种组合下来，成本增加大概在10%到20%之间，换来的可靠性提升是数量级的，这笔账非常划算。
6.3 难点三：架构的关键是“最小”，不是“完备”
这个标题的精髓我越做越觉得在“最小”两个字上。完备的诱惑是让人什么都想加，但一个塞满了组件的架构，本身就会变得混乱和脆弱。最小完备架构的目标不是“功能多”，而是“自洽和可持续”。每个新增的组件都应该问一句：它是不是闭环运行所必需的？如果不是，就先别加。
我自己就吃过这个亏。有一版系统我加了复杂的用户画像模块、动态Prompt模板库、多Agent协作调度器——功能确实多了，但系统状态变成了一个巨大的不可控矩阵，连调试都困难。后来我狠心砍掉一半，回到“五部件正循环”的简单形态，各项指标反而回升了。这件事让我透彻地理解了“最小”的价值。架构的最小化，不仅是技术洁癖，更是工程上的理智选择。
6.4 现在最适合做的一件事：先攒一份“失败轨迹”
如果你现在还是0到1阶段，不需要马上搭建完整系统。我建议你从一件最不起眼、但长期价值最大的事做起：记录失败。
把你当前系统每一次任务的完整轨迹——目标是什么、哪个步骤出了问题、最终结果差在哪儿——全部保存下来。不用做复杂的分析，先存着。这份“失败轨迹清单”就是搭建记忆系统和自评估器最好的原材料。等你要训练自评估器、设计纠错策略、做架构重构的时候，这份数据会让你节省大量收集成本。
同时，我建议你也开始对自己提一个简单的问题：当前系统最常在哪一类问题上翻车？是信息获取不完整、中间计算错误、还是工具调用格式不对？找到那个最高频的失败点，这就是你的第一个“闭环补丁”应该打在的地方。
回到标题那句“可能是关键”的措辞——我做项目时习惯性地保持谨慎。但真做了几轮实验之后，我现在更愿意把“可能”两个字去掉：对于让智能体走向真实场景这件事，一个带自评估、有记忆、能闭环的“最小完备架构”，不是众多可选思路中的之一，而是必须先于模型能力、先于功能丰富度去打好的一道地基。模型可以慢慢换，工具可以慢慢加，但闭环这根骨架，得先立起来。
