这周掘金上一篇少见的架构复盘长文：一位 AI 工程师详细记录了一支团队在 2026 年 1 月到 9 月期间，如何对一个投资研究 Agent（能自主规划多步任务的 AI 助手）做架构重构——最终得出一个判断：模型负责语义，Runtime（模型之外的运行环境，负责调度与状态）负责过程，MCP（连接模型与工具/数据的标准接口）负责能力，Skill（可复用的方法包）负责方法。

技术性很强，但信号比代码更重要：做一个“能稳定工作”的 Agent，难点已从“模型够不够聪明”转移到了“谁该管什么”。

这是什么

作者团队早期让模型在输出下一步动作时，附带维护一份 Runtime 状态镜像——剩余次数、权限、取消标记等。结果发现模型既要理解问题，又要重复维护“系统本就知道的事实”，后者很贵且毫无权威性。

之后他们把所有确定性逻辑（授权、预算、checkpoint、恢复）下沉到 Runtime，又发现 Runtime 越接越重，开始接管业务能力定义。2026-09-26 那次重构用 438 个文件、3,915 个测试用例，把原本分散在三处的工具定义收敛成一个 Tool Contract。

截至 2026-09-30，文章给出的总结是：语义决策可以交给模型，权威与恢复不能。

行业怎么看

这种深度的架构复盘在中文技术社区不多见。多数 Agent 文章讨论的还是“换更大的模型”、“加更多工具”，很少有人讲 Runtime 与 Model 的边界。

但有三个值得对照的判断。第一，这是一家金融研究 Agent 的经验，工具链复杂、状态密集；普通客服问答型 Agent 用不到这套四层分工，照搬会过度设计。第二，MCP 作为协议本身还在快速演化，今天按 MCP 设计的调用层，明年可能要重写。第三，438 个文件、3,915 个测试用例的工程量，只有投入相当的团队才撑得起，小团队照搬会先被维护成本拖垮。

对普通人的影响

对企业 IT：评估 AI Agent 厂商时，请直接问“你们的 Runtime 和模型之间状态怎么切分、失败如何恢复”。能讲清楚的厂商值得认真看；讲不清楚的，演示再漂亮也是薄纸一层。

对个人职场：日常用的 AI 写作、Agent 类工具“几乎能用但总掉链子”，根本原因正是这类架构问题，不是你的用法不对。

对消费市场：消费级 AI 产品越简单越好。这套重型架构适合企业级 Agent，普通用户不需要为“语义清晰”付溢价。