上一篇《工信部把“智能体软件”写进专项行动》里，我用过四个口语化的说法：认得清、接得上、推得动、兜得住。这一篇顺着往下看一个问题：Agent 已经能够读告警、查日志、调工具，第一轮判断往往又快又准。但麻烦常常从第二轮才开始——凌晨一点那场故障处置，恰好卡在这里。为什么一个会干活的 Agent，仍然撑不起“持续推进同一项工作”？

工信部 9 月发布的《“人工智能+软件”专项行动实施方案》，在部署智能体软件技术基础时提出，加强智能体“运行框架”等工程化技术研究；9 月 11 日的官方新闻发布会进一步提到“复杂任务可靠执行”和多智能体协同作业。

这些表述并不是《AI Native 产品架构》里 Runtime Architecture 的官方对应物，两者也不能直接画等号。但它们碰到的是同一类现实问题：Agent 开始执行之后，软件怎样让一项工作继续往前走，而且中间不丢状态、不越边界。

看一个生产系统故障处置就很容易理解。凌晨一点，某个服务在新版本发布后持续报错。Agent 可以读告警、查日志、比对发布记录，再调用诊断工具。第一轮往往很漂亮：它很快定位到异常时间点，找出可疑配置，甚至给出回滚建议。

麻烦通常从第二轮开始。十分钟后又来了新告警，刚才的回滚只完成了一半，流量已经切走一部分，下游服务出现了新的症状。此时系统面对的已经不是“再查一次日志”，而是同一项故障处置工作在继续变化。

一、先把“这到底是哪项工作”认清楚

如果每一轮都靠新的 Prompt 把背景重新讲一遍，Agent 就得反复猜：现在处理的还是不是刚才那次故障？刚才已经确认的判断还算不算？哪些动作已经执行，哪些只是建议？当前谁在值守，谁有权决定回滚？这类信息一旦散在聊天记录、日志片段和人的脑子里，系统就很难保持连续。

Work 在这里不是一个任务标题，也不是一条待办。它代表的是一项需要持续推进、会不断接收新事实、产生新判断并形成后续行动的工作。Workspace 则给这项 Work 一个稳定的承载空间，把参与者、对象、材料、工具和状态组织到一起。Shared Work State 记录当前已经被系统接受的工作状态，Context 决定这一轮运行时哪些信息仍然有效、哪些信息需要被带进来。

回到故障场景，告警编号、发布批次、当前影响范围、已执行动作、未完成动作、最新诊断结论，这些都不能每轮临时拼。状态一旦没有权威来源，Agent 的单次能力越强，后面越容易出现“第一次分析对了，第二次却从旧前提继续推”的问题。

二、Knowledge 和 Memory 也不能混成一个“资料池”

生产故障里会同时用到两类信息。一类相对稳定：系统拓扑、运行手册、回滚规范、变更窗口规则、接口依赖，这些属于可复用的知识。另一类来自这项工作本身：上一次相似故障最后是怎样恢复的，这次临时放开了什么限制，哪个判断后来被推翻，某个处置动作为什么被人工否决。这些信息对后续工作还有价值，但它们的来源、时效和使用范围与知识不同。

三部门《智能体规范应用与创新发展实施意见》把“长期记忆”列入智能体技术攻关方向，也提出完善研发、测试、部署、运维等工具链。这里的“长期记忆”可以作为现实锚，说明行业已经开始正面处理跨轮次、跨时段的信息连续性问题；它并不等于《AI Native 产品架构》里的 Memory Architecture。

产品里如果只做一个“大记忆库”，很快会遇到另一个麻烦：旧结论和新事实混在一起，历史经验与当前有效状态混在一起。Agent 记得越多，不代表它这一轮拿到的信息越对。持续工作需要的不只是“记住”，还要知道什么可以复用、什么已经失效、什么只属于某一次 Work。

三、能力都有了，为什么每一步还得靠人重新指挥

很多 Agent 产品已经具备相当完整的能力：能读数据、能调接口、能生成方案、能执行工具。问题是，一步做完之后，下一步往往又回到人手里。人要重新看结果、补上下文、告诉系统“继续查这里”“先别回滚”“把范围扩大到下游”。如果每完成一步都需要人重新组织工作，Capability 已经有了，Runtime 还没有接上。

Capability Architecture 解决“系统能够做什么”。在《AI Native 产品架构》的正式结构里，它由 Workspace、Context、Knowledge、Memory、Agent 共同构成。Runtime Architecture 解决“这些能力怎样围绕同一项 Work 持续运行”，其中 Work Loop Engine 与 Governance Architecture 在运行时协同，不是一个先执行、再治理的流水线。

故障处置里，一次诊断结束之后，系统需要根据最新状态判断：证据够不够，原来的假设是否仍成立，要不要继续调用工具，是否需要等待外部结果，是否已经触发人工接管条件。工信部新闻发布会里提到“复杂任务可靠执行”，恰好把这种现实需求说得很直白。这里仍然要保持边界：政策在描述产业任务，我们用自己的产品架构框架解释软件为什么会在这些位置断。

能力进入运行时，才有“持续工作”

四、Governance 不能等事情做完以后再补

只要 Agent 开始碰生产环境，治理就不可能只放在审批页面和审计报表里。重启服务、切换流量、修改配置、回滚版本，这些动作有的可以自动做，有的需要特定角色授权，有的即使技术上可执行，也要等业务负责人确认。能力、系统权限和这一次的业务授权不是一回事。

工信部 9 月 11 日新闻发布会在谈智能体软件安全时用了几组很具体的表述：产品环节要“行为可控、全程可溯”；直接进入生产一线的工业智能体要“安全可靠、行为可校验”；在智能服务标准方面，还提出明确“服务交付质量和责任边界”。这些要求都指向运行过程本身，而不是事后补一份日志就结束。

更容易被忽略的是 Action、Effect 和 Responsibility 之间的距离。Agent 调用了回滚接口，接口返回成功，只能说明 Action 成功。流量是否已经全部切回，旧版本是否恢复，依赖服务是否同步恢复，还需要单独核验 Effect。即使 Effect 已经成立，责任也不会因为“这一步是 AI 执行的”就自动转给 AI。谁批准、谁承担业务后果、出了异常谁接管，仍然要在产品和组织里说清楚。

所以 Governance 需要和 Work Loop 一起进入 Runtime：该继续的时候允许继续，该停的时候能停，该交人的时候把状态和证据一起交出去。否则软件看起来在自动推进，风险却可能只是从人的显性判断里被挪到了系统内部。

五、Capability 和 Runtime 的接缝，通常从这些地方先裂开

把上面的故障场景摊开看，很多问题并不是“模型不够聪明”，而是能力进入运行时之后没有接牢。可以用下面这张表做一次很实用的排查。它只是接缝检查，不是新的五层架构，也不改变《AI Native 产品架构》里 Capability Architecture 与 Runtime Architecture 的正式定义。

六、Agent 会干活，和软件能持续推进同一项工作，是两个问题

Agent 的单次执行能力还会继续变强。读更多数据、调更多工具、把一次任务做得更快，这些都会不断进步。但当软件开始参与真实工作，产品设计会遇到另一组问题：这项 Work 的身份在哪里，状态由谁维护，当前 Context 怎样形成，Knowledge 和 Memory 怎样使用，能力如何进入下一轮运行，什么时候自动继续，什么时候必须停下，动作是否已经形成 Effect，责任最后落在哪里。

这些问题不会因为模型再强一档就自动消失。它们属于软件本身。

所以我现在看一个 Agent 产品，会把两个问题分开：它能做多少事，以及这套软件能不能让这些能力围绕同一项 Work 持续、受控地工作下去。前一个问题决定能力上限，后一个问题决定它能不能进入长期、复杂、真实的业务。

下一篇架构篇会继续看一个更具体的问题：系统都接上以后，谁来维持一项工作的连续性。

1. 工业和信息化部：《“人工智能+软件”专项行动实施方案》https://www.miit.gov.cn/zwgk/zcwj/wjfb/tz/art/2026/art_49783ce685f042029111c8b6e94f0f30.html

2. 工业和信息化部：《“人工智能+软件”专项行动实施方案》新闻发布会https://www.miit.gov.cn/xwfb/xwfbh/bxwfbh/art/2026/art_95c0b992336a4cb1b87ec3ccc576a669.html

3. 工业和信息化部：七问+一图，读懂《“人工智能+软件”专项行动实施方案》https://www.miit.gov.cn/jgsj/xxjsfzs/gzdt/art/2026/art_45df9463e105446c996568f299e07bca.html

4. 国家互联网信息办公室、国家发展和改革委员会、工业和信息化部：《智能体规范应用与创新发展实施意见》          https://www.cac.gov.cn/2026-05/08/c_1779979789523320.htm

「下一代软件」持续更新

这个合集会继续写 AI 进入软件以后，产品和系统正在发生的变化。从 Agent 怎样参与真实工作，到 Capability、Runtime、Governance，以及软件怎样从 Function 走向 Work，一篇篇往下讲。。

如果你也在关注下一代软件会怎么变、Agent 进入现有系统后还缺什么，可以关注「AI Native 架构笔记」。