BorisAgent 缘起——AI 的底盘不是“智能“，是“治理“

一个起点我最初的想法很简单做一个能调用 LLM 执行决策的 Agent。那时我在做一个 3D 模型修改的项目我叫它 3DAIAgent目标是用自然语言驱动 Blender 给机甲模型加细节。它的骨架和市面上大多数 Agent 教程一模一样一个命令分类器、一个意图解析器、一个规划器后面跟着一条流水线式的执行链。我还特意把自己对上下文管理和执行链管理的理解塞了进去——看起来五脏俱全。跑通 demo 的那一刻我甚至觉得这事快成了。但很快我就高兴不起来了。一个困惑这玩意儿有什么特殊之处因为把这条链做完之后我产生了一个疑惑这玩意儿有什么特殊之处吗有什么难点吗能商业化吗够企业级吗LangChain 有 chain 和 memorySemantic Kernel 有 kernel 和 plannerAutoGen 有多智能体对话。我的 Agent 无非是把这些概念用自己的方式重写了一遍再套上一个 Blender 场景。把场景换掉它就是网上任何一篇手把手教你写 Agent教程的课后作业。更让我不安的是代码本身暴露的缺陷无状态——每次请求都是一次独立的管道调用任务跑到哪了、失败在哪一步进程一退就全丢硬编码——加一种命令类型要改一串 if-else弱类型——模块之间靠 Dictionarystring, object 传数据字段有没有、类型对不对全靠自觉。为了解决这些问题我试着引入了StateBased也就是状态机概念后来才知道其实LangGraph也是状态机架构。我马上在 3DAIAgent 上做了一次小范围验证把那条无状态的管道改造成以 TaskObject 为核心的状态驱动架构——显式生命周期draft → validated → bound → planned → ready_to_execute → executing → completed/failed、分层字段所有权、操作注册表。真实 Blender 冒烟测试第一次跑通了加载任务文件 → 执行 → 保存副本 → 写报告的完整闭环。那次验证让我确信这条路是对的而且它不该只属于一个 3D 建模工具。测试规模从几十个涨到 366 个以单元测试为主其实这些测试都是GPT自己写的不得不说现在VibeCoding提升的工作效率不是一点点同时也让我感到焦虑这意味着程序员的职业正在遭受AI冲击。一个追问AI 的底座到底是什么做到这里的时候那段时间正好在和公司同事探讨未来AI和Agent的现在大家都在追求的目标是让AI越来越聪明等到AI真的足够聪明的时候Agent还有存在的必要吗他觉得在AI越来越聪明的路径上躺着所有Agent公司的尸体。他这话没错但是我仍然觉得Agent不会死只会变化升级那么是否这其中有什么东西是最基础最基本的不会变的呢否则如果Agent没有存在的必要了那我现在的工作是不是就也没有意义了我想这应该是不对的所以我的问题是这个不变的——AI 的底座——到底是什么应该是什么决定 AI 能用到什么地步的因素很多模型能力、数据质量、算力规模、Prompt 工程……这些都没错。但当我亲手做了一个 Agent 之后我隐约觉得我们漏掉了什么。我们缺一个框架。不是那种帮你更快调 LLM的框架而是一个企业级的能约束 AI 的框架。当时还只有一个比较模糊的念头直到我想起来我手上维护的一个项目正好它的架构是长任务治理类型的这好像正好能强化我的那个架构雏形。一个灵感来自于老项目的架构我做过一个企业级数据治理项目的维护。那个领域我发现了一个似乎是我一直在寻找的点长周期任务的治理。一个数据清洗任务可能跑几个小时甚至几天那么必然要面对的几个经典问题就是任务跑到一半失败了怎么办不能从头再来要能从断点恢复。谁来保证任务可恢复、可审计每走一步都要留痕——谁、何时、做了什么、结果如何。人怎么在关键时刻介入系统要能在某个节点挂起等人决策之后再继续。我翻出代码笔记MasterContext——一个不可变身份加可变负载的执行状态容器FlowToken 路由内嵌在上下文里的统一响应逐步追加的执行单元记录。这不就是一个状态机吗而 Agent 不就是一个任务执行器吗LLM 负责决策做什么剩下任务怎么推进、失败了怎么办、怎么证明发生过什么全都是状态机的地盘。更重要的是我开始看清那个漏掉的东西是什么了。LLM 的发展速度远超所有人的预期。今天的 GPT/Opus/DeepSeek 已经能做很多事明天的 AGI 只会更强。但越强大的东西越需要约束。就像汽车现在因为新能源的发展汽车的马力是越来越大百公里加速时间时越来越短。马力越大刹车和底盘调教越重要否则很容易失控冲到草坪上去。AI也是同理Agent刚火的时候不是有个OpenClaw就很说明问题。我们需要更快的引擎但是也需要一套能让 AI 在轨道上运行的底盘。最终答案治理运行时这个底盘就是治理运行时。想清楚之后再去看 Agent 生态就比较清晰了现有框架几乎都在解决同一件事如何让 LLM 做决策。如何更好地规划如何更准地调用工具如何更流畅地多轮对话。但很少有人在解决另一件事决策错了怎么办。LLM 会选错工具会生成错误的参数会在执行到一半时遇到网络超时。而一个工具调用可能已经产生了副作用——扣了款、发了消息、写了文件。这时候AI的聪明劲儿似乎不够用了我们需要一个能兜住这种意外情况的。企业级场景要的不是更聪明的 Agent而是更可靠的 Agent。可靠的含义有三个确定性AI 可以灵活但补偿和状态流转必须是确定性的运行时代码——可测试、可预测。可恢复性进程崩溃后任务能从磁盘精确恢复到断点而不是重头再来。可追溯性任何一次状态变更都有不可篡改的记录出问题能复盘合规能举证。这三条加起来就是治理运行时的核心命题。它和 LLM 框架不是竞争关系——LLM 负责智能治理运行时负责可靠各管一段。没有治理的 Agent 是玩具没有 LLM 的治理是空壳。更进一步说即使 AGI 真的到来它仍然需要这套底盘。 因为 AGI 不会消除不确定性——它只是把不确定性的层级从工具调用提升到了意图理解。你仍然需要知道它做了什么、做对了没有、做错了怎么回滚。治理不是 LLM 时代的过渡产物而是 AI 系统永恒的基础设施。BorisAgent把治理思想落地所以这就是我的答案——BorisAgent把长任务治理框架的思想系统地应用到 Agent 领域。洋葱架构一条红线它是一个基于 .NET / Semantic Kernel 的框架用洋葱架构组织。最内层的 Core 是纯接口和模型零外部依赖连 Semantic Kernel 都不知道治理机制内建在 Flow 层Infrastructure 提供可替换的存储、遥测、并发实现。依赖方向永远向内。┌──────────────────────────────────────┐ │ BorisAgent.Server │ ASP.NET Core 宿主 │ 入口与配置 │ │ ┌──────────────────────────────────┐ │ │ │ BorisAgent.Hosting │ │ DI 组装AddBorisAgent() │ │ ┌────────────────────────────┐ │ │ │ │ │ BorisAgent.Flow │ │ │ 编排、路由、治理机制 │ │ │ ┌──────────────────────┐ │ │ │ │ │ │ │ BorisAgent.Core │ │ │ │ 接口 模型零外部依赖 │ │ │ │ 契约与领域逻辑 │ │ │ │ │ │ │ └──────────────────────┘ │ │ │ │ │ │ ┌──────────────────────┐ │ │ │ │ │ │ │ BorisAgent.Infra │ │ │ │ 存储 / 遥测 / 并发实现 │ │ │ └──────────────────────┘ │ │ │ │ │ └────────────────────────────┘ │ │ │ └──────────────────────────────────┘ │ └──────────────────────────────────────┘ ↑ 依赖方向永远向内这条红线意味着Core 层编译时不引用任何第三方包测试时可以只 mock 接口演进时可以整体替换实现而 Core 层的领域逻辑纹丝不动。依赖倒置的实证这不是纸上谈兵。举一个具体的例子审计接口的设计。我把审计拆成两个接口——IFlowAuditor何时审计属于编排语义和 IEventStore审计写到哪里属于存储细节。为什么拆因为何时审计是编排引擎的责任审计怎么存、怎么防篡改是基础设施的责任。把这两件事耦合在一个接口里是很多审计系统后期改不动的根源。类似的倒置还有三组持久化IContextRepository 在 Core实现在外、AI 能力IAgentCapability 在 CoreSK 适配在 Flow、记忆存储IMemoryStore 在 Core实现在 Infrastructure、路由IFlowRouter 在 CoreDefaultFlowRouter 在 Flow。每一组都遵循同一条规则内层定义契约外层实现细节。五大治理机制它提供五大治理机制生命周期管理AgentTask/AgentStage 两级任务模型显式状态机Pending → Running → Suspended → Completed/Failed/CompensatedStage 之间的转移由确定性规则引擎校验不是 LLM 自由跳转。Saga 补偿协同式 Saga每个能力自带补偿逻辑失败时引擎逆序调用回滚补偿本身失败也不级联任务仍会进入终态不卡死。断点续传任务和上下文持久化到磁盘进程被 kill 后重启RecoveryManager 定位断点 Stage当前以 Stage 为恢复粒度更细粒度的 Step 级恢复在规划中跳过已完成步骤继续执行。全链路审计事件追加写SHA256 哈希链防篡改可校验完整性还可以仅凭事件流重建完整任务状态。人工介入HumanInLoop 阶段挂起任务外部信号批准或拒绝超时自动升级。治理运行时 vs 传统 Agent 框架维度传统 Agent 框架BorisAgent治理运行时核心关注点​如何让 LLM 更聪明如何让 Agent 更可靠状态管理​无状态每次请求独立有状态显式状态机失败处理​重试或报错Saga 补偿 断点续传审计​通常没有SHA256 哈希链防篡改人工介入​不支持HumanInLoop 挂起/审批这些我已经基本成型了并且有一组破坏性测试包括注入 Stage 故障、模拟补偿二次失败、用 Mock 假装磁盘写入失败、篡改审计事件试试哈希链能不能逮住、直接在进程外 kill 掉再恢复等。写在最后BorisAgent 还远未成熟。参数准确性、更细粒度的恢复策略、更强的并发控制……要做的事还有很多。接下来真正核心工作是把这个架构打磨成企业级应用。更重要的是我希望这篇文章能引发一个讨论在 LLM 飞速发展的今天我们是不是太关注让 AI 更聪明而忽略了让 AI 更可靠 当 AGI 真正到来的时候我们需要的不只是强大的大脑还需要一副可靠的骨架。如果你也在思考 Agent 如何从 demo 走向生产欢迎 Star 项目、提 Issue 讨论或者直接看看那 97 个测试用例——它们比这篇文章更能说明 BorisAgent 的设计哲学。