这两天，我做了一次很大的产品改造。
表面看，是把一个智能体平台从原先版本升级到第二版本。实际做完才发现，真正被换掉的不是页面，也不是几个接口。
被换掉的是平台对“运行”的理解。
原先版本能跑。它有前端，有后端，有 Skill，有知识库，有对话画布，也有一个自研的智能体运行时。
问题是，能跑和好用之间，还有一段很长的路。
尤其是当你想把它拿去做 POC，拿去服务真实企业流程，拿去承接长链路任务时，很多小问题会一起冒出来：流式响应不断线，工具调用不漂移，产物要能下载，超时要能解释，权限要能收住，用户等了几十秒也要知道系统还活着。
这些问题单看都不大。合在一起，就是一个运行时工程。
一、真正的产品改造，常常不是加功能
很多团队做智能体平台，会先盯页面。
能不能创建 Agent。能不能绑定 Skill。能不能接知识库。能不能在画布里流式回答。
这些当然重要。但做久了你会发现，页面只是入口。真正决定平台上限的，是后面那条看不见的运行链路。
原先版本的结构很典型：
前端是 React + Vite + Ant Design。
后端是 NestJS + TypeORM。
数据默认落在 SQLite。
模型调用走 OpenAI 兼容接口，对接百炼模型。
另起了一个智能体运行时，用独立服务暴露对话接口。
运行时内部接工具、技能、文件产物和多步执行逻辑。
这套结构适合验证 Demo，也适合把想法快速跑起来。
但它有一个隐含代价：产品平台、运行时、工具桥、队列、长任务、文件工作区、对话历史，容易长在一起。
一旦你要做真实 POC，就不只是“让 AI 回答”。你会开始关心一个问题：
这条任务链路出问题时，到底是哪一层在负责？
二、原先版本的难点，不是“不智能”
原先版本的问题不是能力少。
恰好相反，它能力太多了。对话、Skill 执行、知识库、工具路由、附件解析、产物管理、MCP、自动化、评测、监控，都往一个平台里长。
我在原先版本里看到几个关键位置。
一个是后端的 AI 服务。它负责对话、模型调用、工具选择、Skill 触发、附件解析、知识库上下文。
一个是 Skill Runtime。它自己有队列、事件、产物追踪。
还有一个独立运行时。它负责创建 Agent，加载 Skill，跑流式输出，管理会话。
这条路不是错的。
如果你是在研究 Agent Runtime，当然可以这么做。你能深入理解工具、记忆、规划、子任务、上下文管理这些机制。
但如果你的目标是做一个企业智能体产品，麻烦会慢慢出现。
你会在产品层处理运行时问题。你会在 API 层处理队列问题。你会在对话接口里处理长任务。你还会在演示现场处理模型服务、文件系统、数据库锁、临时网络、SSE 断流。
最后平台会越来越像一个自研操作系统。
这很有成就感，也很容易把人拖住。
三、第二版本先做了一个减法
它没有先推倒前端。原先版本前端页面、路由、交互方式，基本保留。工作台、Agent 创建、对话画布、Skill 广场、MCP、知识库、记忆、自动化、评测、监控、流程架构，都继续存在。
真正重起的是后端和运行层。
第二版本变成了一个更清楚的产品架构：
产品前端：保留原有交互，让使用体验不断档。
产品中心：承接账号、Agent、Skill、知识库、流程架构和配置。
协议中心：定义任务、租户、沙箱、工具策略、模型配置和运行事件。
执行网关：负责流式运行、心跳、取消、沙箱、内核调用。
执行内核：承接多步任务、工具调用、上下文管理和产物生成。
这个结构最大的变化，是把“产品系统”和“执行内核”拆开。
前端仍然只知道平台 API。业务侧仍然只看 Agent、Skill、知识库、流程架构。中间多出来的，是一个稳定协议层。
协议层的意义很大。
它让平台可以说清楚：这次运行属于哪个租户，来自哪个线程，用哪个模型，允许哪些工具，沙箱在哪里，最大执行多久，事件如何回传，失败如何标记。
有了这个协议，当前内核只是第一个内核。
以后你想切别的智能体，也不需要重写产品，只需要替换内核适配层。
四、共同的底层逻辑：先有流程架构，再有智能体
但如果只讲“换内核”，还没有讲到这套产品最核心的产品观。
不管是原先版本，还是第二版本，它们共同的底层逻辑都不是“先造一个 Agent”。
而是先有企业架构，先有流程体系，然后才有智能体。
我更愿意把智能体看成一种新的流程支撑能力。
它不是凭空长出来的。它应该挂在端到端流程上，挂在业务架构上，挂在岗位、规则、知识、系统动作和风险控制点上。
所以平台里才会一直保留流程架构视图。
比如从战略到执行、市场到线索、线索到回款、采购到付款、产品到上市、订单到交付、问题到解决。这些不是装饰性的目录，而是智能体能力的坐标系。
沿着这个坐标系，才知道哪个流程节点需要 Agent，哪个节点适合沉淀成 Skill，哪个位置应该接知识库，哪个位置必须保留人工确认。
这也是我和很多“随便造一个智能体”做法最不一样的地方。
智能体不是一个孤立按钮。它应该支撑整个流程体系。
流程管理过去沉淀了很多资产：流程图、制度、SOP、表单、审批规则、岗位职责、风险控制点、知识库、指标口径。
如果这些资产不能和 Agent 串起来，那智能体就只是一个聊天入口。
如果这些资产能够被重新组织成 Agent、Skill、知识库和运行协议，那流程管理就会从“文档体系”变成“可执行能力体系”。
五、执行内核在这里不是一个“模型供应商”
这点很关键。
第二版本里，执行内核不是普通模型下拉框里的一个选项。它更像平台的运行底座。
模型可以走企业自己的 AK。比如平台登记百炼、DeepSeek、OpenAI 兼容网关。执行内核负责上下文、工具、执行框架、权限模式和长任务编排。
默认链路是：业务模型由企业自己配置，执行内核承接多步任务和工具编排。
如果企业明确要走某个内核自带的官方额度，也应该单独配置，不能混进普通业务模型。
这不是小细节。
企业 AI 平台最怕的，是把“谁负责推理成本”“谁负责执行能力”“谁负责权限边界”混在一起。
混在一起，采购不好解释，治理不好解释，出了问题也不好解释。
拆开以后，表达就清楚了：
平台管业务对象，协议管运行合同，执行网关管过程，内核管复杂智能体能力。
六、长链路响应，才是智能体平台的分水岭
做普通聊天，十几秒没有结果，用户还能忍。
做企业流程任务，不行。
因为企业任务不是一句话。它可能要读附件，查知识库，调用工具，生成文档，写入工作区，再把产物返回给用户。
这时，SSE 不是一个前端效果。它是运行状态的生命线。
第二版本的执行网关里有更明确的流式边界。它对前端输出事件，对下游调用内核适配层。中间持续发心跳。运行结束时，统一发完成事件。错误时，统一发错误事件。前端断开、下游取消和内核中止这条链路，也可以继续收紧。
这就比“一个 API 请求里等模型慢慢吐字”稳得多。
原先版本的并发评估也指向同一个问题：长任务压在 Web 请求链路里，SSE 会长期占住后端连接；内存队列、本地文件、SQLite、进程内对话状态，都会在并发时放大风险。
第二版本还不是最终形态。现在 MySQL、Redis、对象存储、规范化审计表、任务队列这些能力还要继续演进。
但方向已经对了。
先把运行时从产品 API 里拿出来。再让执行网关承接任务。再用协议把事件、状态和产物标准化。
七、这次改造真正留下的，是一个可替换内核
我越来越觉得，企业智能体平台不应该把自己做成某个 Agent 框架的外壳。
框架会变。模型会变。工具协议会变。运行内核也会变。
今天你可能接一个成熟内核。明天你可能要接另一个更强的智能体。后天你可能要把某些任务交给内部私有 Agent，把某些任务交给云端执行器，把某些任务交给浏览器自动化。
如果平台从一开始就把运行内核写死，后续每一次切换都会变成一次大手术。
这次改造的价值，是把这件事提前想清楚。
产品上，仍然是 Agent、Skill、流程、知识、评测、监控。
工程上，变成 API 兼容层、协议中心、执行网关、内核适配层和执行内核。
这相当于给平台留了一个“内核插槽”。
智能体平台真正要长期经营的，不是某个内核本身，而是内核之上的业务资产：流程模型、技能资产、知识资产、权限策略、运行日志、评测基准、交付模板。
这些资产沉淀下来，平台才有复利。
八、给企业 AI 产品的落地建议
如果你也在做类似平台，我建议先别急着把所有能力都塞进 Agent。
第一步，先把你要承接的任务分成三类。
短任务，比如问答、摘要、分类、结构化提取，可以直接走模型服务。
中任务，比如生成一份报告、审查一份合同、跑一次流程诊断，需要工作区、产物、事件和重试。
长任务，比如多系统协同、跨角色审批、带权限的流程自动化，必须先设计队列、沙箱、审计、人工确认和异常暂停。
第二步，先画清流程架构，再抽平台内部协议。
流程架构回答“能力应该挂在哪里”。平台协议回答“能力应该怎么运行”。
不要一上来就纠结用哪个 Agent 框架。先定义清楚任务请求长什么样，事件回传长什么样，工具权限怎么表达，产物怎么归档，失败怎么恢复。
第三步，把能力沉淀成 Skill。
一个高频流程节点，不应该只沉淀一段 prompt。它应该沉淀为可复用的能力单元：输入、输出、适用场景、调用边界、知识来源、人工确认点、评测样例。
第四步，再选择内核。
你可以用外部成熟内核，可以用自研 Agent Runtime，也可以在某些场景里用普通 LLM 加工具函数。关键不是名字，而是它能不能被协议接住。
第五步，保留降级，但别让降级掩盖真实问题。
本地联调可以 mock。真实验证必须关闭静默 fallback。否则你以为内核跑通了，其实只是系统悄悄返回了一段模拟结果。
第六步，先挑十个高频流程做验证。
不要从全公司自动化开始。就从十个最常见、最烦、最容易被标准化的流程开始：合同初审、采购需求校验、会议纪要整理、周报汇总、制度问答、线索评分、报销材料检查、项目风险复盘、客户资料更新、招聘简历初筛。
每个流程都问五个问题：触发源是什么，输入材料是什么，系统动作是什么，人工确认点在哪里，失败以后谁接手。
回答完这些问题，再谈智能体平台，才不是概念包装。
九、这次改造，其实是在给产品降噪
我以前很容易被“自己搭运行时”这件事吸引。
因为它很像造一台机器。每个零件都能调，每个工具都能接，每个过程都能解释。
但做产品不是证明自己能造所有零件。
做产品是判断哪些东西必须自己掌握，哪些东西应该交给更成熟的内核，哪些东西要用协议保护起来，免得未来换一次底座就伤筋动骨。
这次从原先版本到第二版本，我最明显的感受是：真正的架构升级，不是堆复杂度，而是把复杂度放到该放的位置。
流程架构要成为第一驱动。
产品平台要沉淀业务资产。
协议中心要沉淀运行合同。
执行内核要承接多步任务。
执行网关要守住长链路体验。
企业 AI 真要落地，靠的不是“这个 Agent 很聪明”一句话。
它需要一套能长期运行、能被审计、能被替换、能逐步扩展的工程底座。
智能体平台的下一步，可能不是做一个更大的智能体。
而是做一个能容纳不同智能体的产品操作系统。