从"在小处编程"到"在大处编程"：AI智能体也要经历这场架构革命

你有没有想过，为什么现在的AI助手用久了会让人有点失望？

它能帮你写一段代码，能陪你聊几轮天，甚至能替你订一张机票。但用上几个月之后你会发现，它好像永远记不住你上次改过的偏好，也永远不会主动告诉你"你之前用的那个方法可能已经过时了"。它更像一个每次都失忆重启的临时工，而不是一个真正陪着你一起把工作越做越顺手的助手。

复旦大学等机构的一批研究者最近写了一篇挺有意思的论文，他们觉得这种失望不是偶然的，而是当前AI智能体的架构从根上就没打算解决这个问题。他们提出了一个叫Pera的框架，试图回答一个听起来简单但其实很硬核的问题：如果一个AI助手要陪你一整年甚至更久，它的"大脑"应该长什么样？

这事儿说来话长，得先从软件工程history里的一场革命说起。

**核心问题：为什么"把任务做完"和"把服务做好"是两码事**

上世纪70年代，软件行业经历过一次认知升级。早期程序员的工作就是把一个个程序写对，这叫"在小处编程"。但当软件系统越来越大、运行时间越来越长之后,人们发现,即使每个模块都写得完美无缺,系统整体照样可能出问题。

因为模块之间的接口对不上、假设不一致、交互方式有冲突，这些"关系层面"的问题，不是靠把某一个模块写得更好就能解决的。于是软件工程发展出了"在大处编程"的思路，专门去管理模块之间的关系、系统随时间的演化、故障恢复这些跨越单个程序生命周期的问题。这就是"软件架构"这门学科诞生的原因。

论文的核心比喻，就是把这场革命平移到AI智能体身上。

现在市面上绝大多数AI智能体，包括那些能连续跑几十个小时处理复杂任务的"超级智能体"，本质上都还停留在"在小处编程"的阶段。它们被设计成解决一个个边界清晰的任务：用户说"帮我订机票"，它就去订机票，订完了任务就结束了，下次你再来，它对你上次订机票时纠结的座位偏好毫无记忆。

论文管这种任务叫**episodic task（情景任务）**

情景任务：有明确目标、明确完成标准的一次性任务，比如"写一份报告""修一个bug"，做完就算结束。

但真实世界里，很多场景根本不是一次性任务能概括的。想象你雇了一个私人助理，Ta的价值不在于"每次交代的事都办好了"，而在于Ta会随着你工作节奏的变化调整自己的工作方式，会在你还没开口之前就发现"你最近的项目风格变了，我该换个汇报模板了"。这种持续的、跨越无数个具体任务的服务能力，论文称之为"长生命周期设定"（long-lived setting）。

论文举了一个特别直观的例子来说明这个差距：计算机使用类智能体。现在评测这类智能体，大多是看它能不能完成用户明确交代的开放式任务。但一个真正成熟的智能体，应该主动感知用户的日常活动变化、感知电脑环境里发生的变化，甚至在用户自己都还没意识到需求之前，就把相关支持准备好。它还得知道，自己现有的决策流程什么时候已经不适应新出现的任务类型了，并主动去修正它。

这里就出现了论文最核心的一个洞察：**持续性的服务，不仅要求智能体知道怎么处理眼前的任务，还要求它能推断出还有什么额外的工作是需要做的，并且判断自己现有的能力是否还够用。**

这句话初看有点绕，但拆开看其实是常识。你雇个助理，Ta光会完成你交代的事还不够，Ta得知道什么时候该主动提醒你，什么时候该更新自己的工作方法。这两件事，恰恰是现在大多数AI智能体架构完全没有考虑进去的。

**为什么"主动感知"是绕不过去的一道坎**

论文接下来花了不少篇幅解释一个概念，叫**主动感知（active perception）**

主动感知：不是被动等待信息进来，而是根据当前的任务和目标，主动决定该关注什么、什么时候关注、关注到什么细节程度。

这个概念其实不是AI时代的新东西，早在1988年就有研究者提出，1995年的"自适应智能系统"架构（AIS）就把它系统化了。论文里提到一个叫Guardian的老系统，是1992年做的重症监护智能体，它会根据病人状况、数据量、计算资源的变化，动态调整自己该盯着哪些指标看，而不是死板地按一套固定流程巡检。

这就带来一个矛盾。一个长期运行的智能体，接触到的信息量是海量的：用户的每一次点击、每一次修改、环境里的每一次变化、系统日志里的每一条报错。如果什么都往里塞，处理不过来；如果什么都不看，就会错过真正重要的信号。

这里论文用了一个特别贴切的类比。就像一个新员工刚入职时会把每封邮件都仔细读一遍，但半年之后，Ta学会了只看抄送给自己且带"紧急"标签的邮件，其他的扫一眼标题就够了。这不是偷懒，而是Ta建立了对这份工作"什么重要什么不重要"的判断力。如果一个AI智能体永远保持"新员工模式"，事无巨细地处理每一条输入，它要么被信息淹死，要么反应慢到没法用。反过来，如果它压根不具备主动感知能力，只会等着用户明确下达指令，那它就永远只是个执行工具，成不了真正的助手。

论文特别强调，单个孤立的事件往往说明不了什么问题。一次工具调用失败，可能只是网络抖动；但如果同一个接口连续失败了好几次，而且失败的时间点都跟某次系统更新对上了，这就不再是偶然，而是一个值得深挖的"信号"。

这引出了论文里一对很重要的区分：**信号（signal）和观察（observation）**

观察：智能体在执行当前任务过程中获得的、用来指导下一步决策的信息，比如用户发来的消息、工具返回的结果。

信号：能被智能体核心架构捕捉到、用来触发跨任务级别判断的变化线索，可能发生在任务进行中，也可能发生在任务结束后，甚至发生在没有任何任务运行的时候。

同一件事既可以是观察也可以是信号。比如一次工具调用报错，既能让当前任务及时做出补救（这是观察），也能作为证据表明某个可复用的流程可能已经过时了（这是信号）。区别不在于事件本身，而在于这个信息被用在了哪个层级的判断上。

**Pera架构：给AI智能体加一层"生命周期大脑"**

理解了这些铺垫，Pera的整体设计思路就清晰多了。

论文把现有的"认知型语言智能体"（cognitive language agent）看作是一个已经比较成熟的执行单元，它有记忆、有工具、有决策流程，能把一个任务从头到尾干完。

认知语言智能体：把语言模型嵌入到带有记忆、工具调用、推理规划能力的系统里，用来完成具体任务的AI架构，代表性框架有CoALA、ReAct等。

Pera要做的，不是重新发明这套执行机制，而是在它外面再加一层"持久智能体核心"（persistent agent core），这层核心由两个部分组成：感知组件（perception）和控制组件（control）。

感知组件负责不间断地捕捉外部和内部的各种信号。外部信号来自人、物理环境、数字环境三个方向：比如用户的行为变化、传感器测到的温度异常、文件系统里出现的新文件。内部信号则来自任务执行过程本身、智能体的记忆库、甚至感知和控制机制自己：比如反复出现的工具失败、记忆里那些一直没被用到、可能已经过时的信息。

控制组件的工作是把这些捕捉到的信号进行加工判断，决定要不要采取行动。如果判断需要行动，它就会生成一个叫"生命周期任务包"（lifecycle task package）的东西，把这个任务派发给具体的执行单元去完成。

这里出现了论文另一个核心概念——**生命周期任务（lifecycle task）**

生命周期任务：目的不是完成一个用户交代的具体活儿，而是为了维护或改善未来所有任务共享的某种持续性条件而设立的任务，比如修正一个已经过时的偏好设置、更新一个不再适用的工作流程。

这个区分很关键。判断一个任务是不是生命周期任务，看的不是谁发起的、也不是它是不是"主动"发起的，而是看它的目的和完成标准。举个论文里的例子：帮用户写一份报告是情景任务，用完就结束；而如果用户说"以后所有报告都用这个格式"，这句话背后隐含的是一个生命周期任务，它要建立一个能持续影响后面所有报告的规则，完成标准不是"这份报告写完了"，而是"这个格式规则真的被固化进了流程里，以后每次都会生效"。

这里可以做一个类比来理解这两种任务的本质差异。假设你请了个装修工人，他今天来给你刷了一面墙，这是情景任务，刷完这一面墙这件事就结束了。但如果他发现你家的电路老化，主动帮你重新布线，这就是生命周期任务，因为电路的状态会影响你之后每一次开灯、每一次用电器，它的价值不体现在"这次干完了"，而体现在它长期改变了整个房子的运行状况。如果工人只会刷墙不会看电路，你的房子迟早出问题，即使每次刷墙都刷得再漂亮。这正是论文想说的：只会做情景任务的智能体，再强也解决不了持续服务里积累的深层问题。

**生命周期任务包：给AI的"改造工程"划好边界**

生命周期任务比普通任务更危险的地方在于，它往往要去修改那些会被未来无数任务复用的东西，比如一段可复用的代码逻辑、一个诊断流程。改错了不是耽误这一次，而是可能连累后面所有依赖这套逻辑的任务。

所以Pera给这类任务设计了一个专门的"任务包"结构，里面至少包含四样东西。第一是清晰的任务目标，说明要达成什么效果、执行完之后要留下什么样的持久性改变。第二是完成标准，也就是执行者要拿出什么证据才能证明任务做完了。第三是执行过程需要的上下文，比如相关的失败记录、当前使用中的旧流程。第四，也是最重要的一点，是恢复机制和审查标准。

论文举了个特别接地气的例子：假设一个自动化助手一直负责帮你提交报销单，结果报销网站换了新界面，助手连续提交失败了好几次。这时候Pera会构造一个生命周期任务，让执行者去研究新界面、修改提交流程，并且要求它拿出"用测试报销单在新界面成功提交一次"的证据才算完成。

但光是"能跑通一次"还不够放心。审查阶段会做更严格的事：把改好的新流程拿去回放之前已经成功过的那些旧场景，只有确认新流程没有破坏原来能用的功能，才会真正替换掉旧流程。

这个设计背后藏着一个很朴素的道理。就像你请人重新布线之前，你肯定希望有人先断电测试一下新线路，而不是直接把老线路拆了。如果没有这层"保留旧版本、验证通过才替换"的机制，任何一次自我修正都可能变成一场事故，越改越乱。如果不设置这道保险，一个自我修改能力越强的AI系统，出错的代价反而越大，这跟软件开发里为什么要有版本回滚是一模一样的道理。

**Pera的行动空间：比现有框架多出的三个动作**

现有的认知型语言智能体框架里，动作空间通常包括推理、检索、更新、落地（也就是跟外部环境交互，比如调用工具）。Pera在这基础上又加了三个新动作：感知（sensing）、派发（dispatching）、实例化（instantiation）。

感知负责持续监测内外部的各种来源，判断什么时候该收集信号、该以什么频率、什么细粒度去收集。这不是一件轻松活儿，因为盯着一切看的成本太高，什么都不盯又会错过关键信息。论文提到一个思路，是让感知机制自适应地调整投入：平时用轻量级监测就够了，一旦出现异常苗头，再启动更精细、更昂贵的检查。

派发负责决定一个生命周期任务什么时候真正开始执行，是立即处理，还是先排队，还是等资源或授权到位再说。这跟操作系统里的进程调度有点像，但复杂的地方在于，情景任务通常有紧迫的响应要求，而生命周期任务往往决定的是未来很长一段时间里服务质量的好坏，这两种任务谁该优先谁该延后，需要一套专门的调度逻辑。

实例化则是把一个通用的智能体规范，套上具体任务的输入，变成一个真正能跑的执行实例。这个动作在传统框架里往往是隐式发生的，用户一发指令，智能体就直接开始干活。Pera把它显式地拆出来，是因为对于生命周期任务而言，这个执行实例还需要额外加载任务专属的操作流程和约束条件，不能一概而论。

**案例研究：模型训练场景里的"隐性错配"**

论文用了一个具体案例来说明整套架构怎么运转，这个案例发生在一个大模型开发的场景里。

设想一个用户在同一个计算集群上，依次完成了四个阶段的工作：先做稠密模型训练，产出模型checkpoint；接着做推理评估，产出性能指标和错误案例；然后根据评估结果做数据处理，筛选和重组训练数据；最后用处理好的数据和之前的模型做混合专家模型（MoE）训练。

**混合专家模型（MoE）**：一种模型架构，让不同的"专家"子网络分别处理不同类型的输入，相比传统稠密模型，它的计算模式和资源需求都不太一样。

这四个阶段各自都是独立的情景任务，各有各的完成标准。但它们属于同一个"长生命周期设定"，因为前一个阶段产出的东西，会持续影响后面阶段怎么做。

到了数据处理阶段结束的时候，情况变得有意思了。累积下来的项目上下文里，已经记录了稠密训练、推理、数据处理各阶段的特征，而即将开始的下一个模型配置和资源计划，都指向了即将转向MoE工作负载这件事。但智能体现有的监控基线和诊断流程，仍然是按照之前稠密训练那套假设写的。

论文管这种状态叫"新兴服务错配"，工作负载已经在变了，但负责维护可靠性的服务流程还没跟上。注意，这个时候没有任何一个具体任务失败，所有情景任务都顺利完成了，问题出在更深一层：未来的服务质量，正在悄悄脱离现实需求。

Pera的做法是，把这个错配转化成一个生命周期任务，专门去修订共享的感知、信号处理和诊断流程，让系统能按照新的工作负载模式去区分什么是正常、什么是异常，同时还得保证对之前稠密训练阶段的支持不受影响。等这个修订被验证通过，后续的MoE训练就能享受到一套已经适配好新场景的可靠性服务，而不用等到出问题之后才手忙脚乱地补救。

论文还拿这个案例对比了几种现有的代表性架构，看它们各自能做到什么程度。像Plan-and-Act这种任务中心型架构，只在当前活跃任务的边界内组织信息，任务一结束，控制权也就结束了，项目级别的依赖关系完全没被纳入持续性管理。A-MEM这种带情景记忆的架构，能让经验跨任务保留下来，但保留下来的经验只是"输入"，除非某个后续任务主动去检索使用它，否则这些经验本身不会主动触发任何维护性的工作。ContextAgent这种上下文感知型主动智能体，能提前感知到工作负载的转变，并主动发起服务，但它发起的仍然是一次性的情景服务，共享的感知和诊断机制本身没有被纳入维护范围。

**几条面向未来的建议**

论文的后半部分，是研究者结合这套架构，给出的几条具体的研究方向建议，这部分内容挺扎实，值得展开说说。

关于感知怎么做得更聪明，论文提出感知的范围应该覆盖人、物理环境、数字系统、内部状态四个维度，而不是只盯着某一类信号源。同时感知的强度应该是可变的，平时轻量巡检，异常时才加大投入，这样才不会把计算资源浪费在无关紧要的信息上。更进一步，智能体自己的传感能力也应该是能进化的，比如随着环境变化去增加新的检测点、修正软件层面的探测逻辑，甚至在必要时通过和物理世界交互去校准或更换硬件传感器。

关于信号该怎么表达，论文提出一个很实际的问题：自然语言太灵活了，同一个状况可能被描述成完全不一样的句子，这给跨时间的信号比对带来了麻烦。论文举了个例子，一个训练集群里出现工作节点变慢、通信延迟升高、任务吞吐量下降这几件事，它们其实都指向同一个通信瓶颈问题，但如果每次都用自然语言随便描述，几周之后再想认出"这跟上次是同一类问题"就很难。论文建议把感知到的事件映射到一种更结构化的、领域专属的信号语言里，这样才有一个稳定的基础去做跨时间、跨来源的比对和聚合。

关于智能体怎么从上下文里学习，论文提出这个挑战已经超出了"在静态知识上做推理"的范畴。真实世界里的上下文往往是杂乱分散的，比如一个员工的工作背景散落在各种对话、文档、历史任务和应用状态里，没有整整齐齐地摆在一处。论文特别提到他们自己团队做的一个基准测试叫CL-bench，专门用来考察模型能不能学习和应用那些训练数据里压根没出现过的新知识、新规则、新流程，结果显示当前模型在这方面还有很大提升空间。而且知识的有效期也是个问题，一个员工换了项目，一条公司政策被修订了，之前学到的东西可能就不再适用，智能体得学会判断"这条信息现在还作数吗"。

关于主动性该往哪个方向发展，论文认为现在的研究大多集中在"给定一个任务，怎么把它做得又快又好"，但对持续性智能体来说，更难的问题是"在没有明确任务的情况下，该不该主动做点什么"。这里有个平衡问题：太激进地主动出击，会打扰用户、带来风险；太保守，又等于放弃了主动性的价值。论文建议根据置信度、预期收益、风险这几个因素去校准主动行动的力度，从"继续观察"到"后台准备"再到"直接询问用户"再到"直接执行低风险操作"，形成一个渐进的响应梯度。

关于智能体的自我改进，论文区分了两个层面：改进智能体的"外壳"（harness，也就是非模型部分，比如工具、技能、记忆机制）和改进模型本身。这两者其实是互补的，外壳提供了快速迭代的灵活空间，而模型能把反复被验证有效的改进沉淀进参数里，变成更稳定的能力。论文还特别提到一个容易被忽视的问题，就是不同组件的进化可能互相打架。比如你给智能体加了个新传感器，暴露出了新的信号，但原有的控制逻辑压根没准备好怎么处理这些新信号；再比如引入了新工具，但决策流程还没跟着调整怎么调用它。所以论文呼吁，自我改进不能只是零敲碎打地改某个组件，得往协调进化的方向去想。

关于评测方式，论文认为现在的智能体评测大多还停留在单个任务或者"长时间执行一个复杂任务"的维度上，但真正的持续服务场景要复杂得多。目标会随时间演变，上下文会不断积累和变化，智能体还得主动支持各种不同类型的任务并且不断调整自己。现有的评测基准，还没能真正捕捉到这种"长期陪伴式服务"的全貌。

**这套架构跟已有的相关研究是什么关系**

论文最后专门讨论了两条跟自己相关但又不完全一样的研究脉络。

一条是持续学习和终身学习。持续学习关注的是模型怎么从不断变化的数据流里学习新东西，同时不忘掉已经学过的老东西，核心问题是"灾难性遗忘"。终身学习的目标更宏大一些，是在一整个生命周期里积累可复用的知识和经验。但论文指出，这些研究大多还是围绕"任务流"展开的，也就是从已完成的任务里提炼经验、用来改善后续任务表现，而Pera想强调的是更广的感知范围，包括那些根本不以"任务"形式出现的变化信号，以及智能体要具备前瞻性地在设定演变过程中不断挖掘新上下文的能力。

另一条是各种通用智能体架构，比如上世纪80年代的Soar认知架构，把感知、记忆、学习、决策、行动统一进一个认知系统；还有BDI架构，围绕信念、欲望、意图组织实践推理。到了大语言模型时代，CoALA把认知架构的思路搬到了语言智能体上。还有像subsumption架构、Hayes-Roth的自适应智能系统，把感知和自适应控制放在架构核心位置，这些直接启发了Pera对感知和控制的重视。但论文指出一个关键差异：在这些老架构里，感知主要是为了支撑当前任务的行为调节，而对持续性智能体来说，感知的目的更广，包括发现尚未浮现的需求、判断服务本身该怎么随设定演变。这个目的上的差异，最终导致了截然不同的架构设计方向：一个是围着"把眼前这件事做对"打转，一个是围着"让整套服务持续跟上变化"打转。

写在后面

读完这篇论文，最触动我的其实不是Pera这套架构本身有多精巧，而是论文反复强调的一个视角转换：判断一个AI智能体是不是"聪明"，光看它单次任务完成得好不好已经不够了，得看它有没有能力意识到"我现在这套方法可能已经不适用了"。

这个判断标准挺狠的，因为它把评价重点从"结果对不对"移到了"自我认知准不准"。一个AI系统可以每次任务都做得完美无缺，但只要它意识不到外部环境已经变了，它其实就是在用一套过时的答案不断重复正确的错误。这跟人类专家的成长轨迹其实是一个道理，一个真正厉害的医生不是每次诊断都精准，而是能敏锐地察觉到"这套治疗方案可能已经不适合当前这批病人了，得更新"。

论文里那个模型训练案例让我印象特别深，倒不是因为技术细节多复杂,而是因为它精准地戳中了一个日常场景。你有没有遇到过这种情况：一个系统、一套流程用了很久都没出过问题，直到某一天你才发现，其实它早就应该更新了，只是没有任何一次"报错"提醒过你。这种"没有失败但已经过时"的状态,可能比明显的故障更难被发现,也更难被修复,因为它压根不会触发任何警报。

论文里提出的CL-bench基准测试，专门考察模型能不能学习训练数据里没有的新知识，这个方向我觉得特别值得追问下去。因为它揭示了一个更深层的矛盾：大模型的"聪明"很大程度上来自于训练数据里已经压缩好的海量知识,但一个真正好用的持续性助手,恰恰需要不断吸收那些训练数据里根本不存在的、专属于你的、随时在变的私人信息。这两种能力可能需要完全不同的机制才能兼顾。

如果哪天你的AI助手主动跟你说"我注意到你最近的工作方式变了，我打算调整一下我的服务流程"，那大概就是这篇论文里描绘的场景真正落地的时刻。

Q&A

Q1：Pera是什么？

A：Pera是复旦大学等机构提出的一种面向持续性AI智能体的架构，全称"以感知为中心的持续智能体架构"，核心是让AI不仅能完成单次任务，还能持续感知环境变化并主动维护和改进自己的服务能力。

Q2：情景任务和生命周期任务有什么区别？

A：情景任务是完成一个具体的、有明确边界的用户需求，做完就结束，比如写一份报告。生命周期任务的目的是维护或改善会影响未来所有任务的持续性条件，比如修正一个过时的偏好设置或更新一套已不适用的工作流程。

Q3：Pera架构相比现有AI智能体框架多了什么能力？

A：Pera在传统的推理、检索、更新、工具调用之外，新增了感知、派发、实例化三个动作，让智能体具备持续监测内外部信号、判断是否需要采取维护性行动、以及安全地执行和审查这些改动的能力。