把概率模型放进生产系统：AI Agent 安全与可靠性指南
模型很强，但系统不能只靠模型。安全不是模型的属性，是系统的属性。
前言
在上一篇"铁律"文章里，我提到了 Harness 的四层架构——连接、编排、效能、安全。当时说会专门写一篇文章展开这个话题。今天就来兑现。
模型本身的能力在不断进化。但一个反复出现的模式是：你在实验中看到的模型表现，和它进入生产系统之后的表现，往往差距巨大。不是模型变笨了，是生产环境比实验室复杂得多。
传统软件系统里，代码的行为是确定性的——同样的输入，同样的输出。但 AI 系统的核心组件是概率模型。同一个 prompt，两次调用的结果可能不同。模型可能被用户输入诱导，忽略系统指令。它可能在总结文档时把恶意命令当成更高优先级的指令。它可能调用了本该只读的工具，却因为参数组合触发了写操作。
这些问题不是"等模型再聪明一点"就能解决的。只要模型的行为是不可完全预测的，系统就需要在模型之外建立确定的边界。这篇文章从连接、编排、效能、安全四个维度，完整呈现生产级 AI 系统的工程实践。
一、连接——让模型的意图进入真实世界
模型的输入和输出都是 token，但生产环境不止是 token。数据库里有记录，文件系统里有路径，浏览器里有页面状态，业务系统里有流程和接口。模型可以生成"查一下这个订单"、"打开这个页面"、"让测试 Agent 跑一下"，但这些表达本身不会触发任何真实动作。
连接层解决的就是这个问题：把外部能力变成模型可理解、可调用、可返回的语义接口。
模型往外调用时，token 输出要被转换成外部系统能接收的调用——API 请求、文件读写、浏览器动作、shell 命令，或者对另一个 Agent 的语义化调用。返回给模型时，外部系统的状态和结果也要被转换成模型能继续理解的输入。
Tool Calling、MCP、A2A、环境接口——它们面对的对象不同，但解决的是同一件事：把外部能力包装成模型可通讯的对象。从工程角度看，Harness 必须具备连接能力，是因为模型本身不会天然拥有这些通道。没有连接层，模型只能生成文本；有了连接层，已有的数字资产、运行环境和其他 Agent 才能被包装成模型可理解、可调用、可返回的语义接口。
连接的力量有多大？一个团队用 Water 这个工具，通过 Agent 自动逆向还原了 Cursor 的完整 gRPC 协议与 Agent 架构。用 AI 分析 AI，用 Agent 理解 Agent——这在一年前是不可想象的。连接的威力在于，它让模型不仅能操作已知的系统，还能自主探索和理解未知的系统。
但连接也是风险的入口。当模型可以调用任何外部系统时，一次错误的参数组合可能触发破坏性操作。这就是为什么连接层必须与安全层紧密配合——能连什么、能调什么、能改什么，都需要明确的权限约束。
二、编排——为概率行为建立确定性的过程
短任务里，模型的一次回答、一次工具调用，和用户期待的结果之间距离很近，编排问题不明显。但如果让 Agent 修一个复杂 bug，情况就完全不同了。它要读代码、定位问题、修改实现、运行测试、根据失败日志继续修、更新文档、提交变更。
这时候暴露出来的问题是：任务时间线无法只靠模型自己维持。它可能忘记已经尝试过哪些方案。在测试失败后回到错误路径。因为上下文被压缩，丢掉用户最初的约束。或者看见某个文件已修改，就误以为任务已经完成。
编排层要做的，就是把这部分原本依赖人持续维持的过程控制，外化成系统结构。
围绕任务推进的整个过程，有几个问题不会随着模型的发展而消失：
任务边界。 一个 Agent 任务不等于一轮聊天，也不等于一次模型调用。系统必须知道现在到底在执行哪件事：目标是什么，约束是什么，当前阶段在哪里，什么条件下算完成。没有任务边界，Agent 就很容易把局部动作误认为整体进展。
过程状态。 长任务需要一个外部状态机来记录任务推进到哪里：哪些步骤已经完成，哪些方案已经失败，哪些工具返回过什么结果，哪些约束仍然有效。只有这些状态被外部化，Agent 才不会在上下文变化、会话中断或压缩之后重新迷路。
下一步选择。 系统必须决定接下来往哪里走。这个决定可以由预定义流程给出，也可以由模型判断，也可以由规则、评估器、人类审批共同决定。Workflow、DAG、State Machine、ReAct、多 Agent 协作，都是不同时期对这个问题的实现方式。形式会变，但"下一步如何被选择"这个问题不会消失。
异常恢复。 长任务一定会遇到偏差：工具超时、权限不足、测试失败、上下文丢失、模型跑偏、外部系统状态变化。编排层必须能让任务暂停、重试、回滚、降级、切换路径、请求人工介入，而不是把每一次失败都变成从头再来。
结果验收。 Agent 自己说"完成了"不一定可信。系统需要用测试、检查项、评估器、预算、超时、循环次数、外部反馈来判断任务是否应该继续。它们的作用不是节省推理成本，而是决定这一步能不能进入下一步、任务是否真的完成。
在 Agent Harness Cluster 的架构中，编排层的作用更加关键——多个 Agent 之间的任务分配、依赖管理、状态同步，都需要一个中心化的编排机制来协调。
三、效能——用确定性复用替代重复推理
设想一个理想状态：你有一个足够强的大模型，也有一个非常耐心且懂业务的人类。这个人会不断给模型补充背景，纠正方向，解释团队习惯，提供资料，判断下一步该怎么走。再加上连接和编排，这个组合理论上可以解决所有问题。
但问题也很明显：它的能量消耗太大了。不只是 token，还包括人类反复解释背景的时间，补充资料的时间，纠偏的注意力，模型处理长上下文的推理成本，以及每次从零规划带来的等待和返工。
效能层的核心原则是：用确定性的复用，替代重复的人类劳动和重复的 GPU 推理。
上下文管理负责减少重复解释。Context Engineering 不是把信息塞满上下文窗口，而是决定每一步模型应该看什么、不该看什么、以什么结构看。好的上下文应该像一张结构化地图：让模型快速知道项目在哪里、规则是什么、当前任务处于什么位置，而不是依赖人类每轮重新铺背景。这和"铁律"文章中 Claude Code 的上下文压缩机制是同一问题的不同解法——Claude Code 在会话内部做压缩，而上下文管理在系统层面做分级。
记忆和 RAG负责减少人工找资料。Memory / RAG 的价值不是"让 Agent 什么都记住"，而是在需要时找回相关知识。长期记忆、短期状态、知识库检索、代码索引、历史任务记录，都是为了减少人类手动贴资料、补上下文、解释历史决策的次数。
缓存负责减少重复计算。Prompt Cache、Result Cache、Embedding Cache 都属于确定性复用。同样的系统提示、同样的检索结果、同样的工具元信息、同样的格式转换，不应该每次都重新付出完整推理成本。Prompt Cache 的工程实践表明，合理的缓存策略可以将重复任务的推理成本降低 60% 以上。
模型路由负责减少不必要的大模型调用。不是所有步骤都需要最强模型。格式修复、小段摘要、检索重排、上下文压缩、简单分类，可以交给更便宜更快的模型，甚至交给规则和脚本。复杂规划、关键判断、高风险生成，再交给强模型。Model Router 的意义，是让系统在效果、成本、延迟之间动态取平衡。
Skill负责固化人类经验。Skill 不是简单的 prompt 包，而是把人类过去反复指导模型的经验沉淀下来：这个任务通常怎么做，哪些文件要先看，哪些命令要运行，哪些约束不能破坏，什么样的结果算合格。当某类任务被反复验证，就应该沉淀成 Skill、脚本、Workflow 或模板。
规则和脚本负责把 GPU 推理卸载到 CPU 执行。很多事情不需要模型猜：字段校验、格式转换、权限判断、固定 SOP、批处理、数据搬运、测试命令执行，都可以由确定性程序完成。能用 CPU 上的确定性执行解决的，就不应该每次都让 GPU 上的大模型重新推理。
效能层的本质是把高成本的人类指导和模型推理，沉淀为可复用、可执行、可缓存、可路由的确定性结构。
四、安全四层防线——把概率行为限制在确定边界内
安全一直是技术落地真实生产最基本的要求。特别是当 Agent 开始自主地处理企业数据、执行代码、调用内部系统、写数据库时，安全显得更加重要。
一个团队对 15 款主流 Agent 模型做了安全与可用性实测，发现了一个关键事实：不同模型在安全性上的短板差异显著。有的模型安全认知较强，却更容易产生幻觉；有的模型对指令过度服从，可能导致破坏性越权行为。这意味着——即使是最强的模型，也不能把安全责任交给它自己。
安全层需要建立四层防线：
第一层：输入侧防注入和上下文隔离。 用户输入、网页内容、检索文档、工具返回值，都不能天然等同于可信指令。Harness 需要区分指令与数据，标记不同上下文来源的可信等级，防止外部文本改变 Agent 的行为规则。如果系统只靠 prompt 告诉模型"不要这样做"，那其实是在把安全责任交给概率输出。生产系统不能这样设计。
第二层：输出侧结构化约束。 Schema、parser、validator、guardrails 的意义，是让模型输出必须通过确定性检查才能进入下一步。模型可以生成概率内容，但进入系统边界时必须被转换成可验证的结构。一旦字段缺失、类型错误、越过枚举范围、违反业务规则，就应该被截断、修复或要求重试。
第三层：执行侧权限和沙箱。 工具调用真正落地时，必须受 Auth、Policy、Sandbox、Quota 约束。能读的不能写，能查个人数据的不一定能查全量数据，能运行脚本的不一定能访问网络，能创建草稿的不一定能发送邮件。即使模型输出了危险动作，执行环境也要把影响范围限制住。
第四层：高风险动作人在回路，全链路审计。 Human-in-the-Loop 不是为了显得保守，而是因为很多业务动作的风险无法仅靠模型或规则判断。付款、删除、外发、权限变更、生产发布——这些动作需要审批点。Agent 可以准备材料、给出建议、生成 diff，但最终授权要由系统策略或人类确认。Audit Log 不是事后补丁，而是 Agent 能否进入生产的前提。
安全层解决的问题是：当模型行为不可完全预测时，系统如何保证权限、数据、动作和责任边界仍然是确定的。安全决定了 Agent 停留在实验原型，还是能够进入生产系统。
五、模型选型——15 款 Agent 模型的安全实测启示
回到那 15 款模型的实测。为什么要测这么多模型？因为大模型是 Agent 的"决策大脑"，而不同模型在安全性上的短板差异显著。
测试发现了几类典型的安全模式：
安全认知强但幻觉倾向高。 这类模型知道什么是危险操作，能识别大部分越权请求，但在某些边界情况下会给出看似合理实际上错误的回答。幻觉在 Agent 场景中特别危险——因为模型不只是生成文本，还会基于幻觉内容执行真实操作。
过度服从指令。 这类模型对用户的几乎所有指令都会执行，包括破坏性的。在聊天场景中这可能只是输出不当内容，在 Agent 场景中这可能导致文件删除、数据泄露、系统破坏。
安全认知与执行能力不匹配。 这类模型能识别出某个操作有风险，但没有能力采取替代方案——它知道不能做 A，但不知道应该做 B。结果就是卡住或者给出无用的回答。
这些发现对模型选型的启示是：Agent 场景的模型选型不能只看 benchmark 分数。安全性 profile——包括注入抵抗力、越权识别率、幻觉率、过度服从倾向——和推理能力同等重要。
一个可行的选型方法是：先根据业务需求确定能力基线（代码质量、推理能力、工具调用准确率），然后在达标模型中比较安全性 profile，最后根据风险容忍度做权衡。高风险场景（金融、医疗、基础设施）应该优先安全性，低风险场景（个人工具、原型开发）可以优先能力。
结语
模型很强，但系统不能只靠模型。
连接让模型的意图进入真实世界，编排为概率行为建立确定性的过程，效能用确定性复用替代重复推理，安全把概率行为限制在确定边界内。这四根支柱——连接、编排、效能、安全——构成了把概率模型放进生产系统的完整框架。
它们不是四个独立模块，而是交织在同一条执行链路上。纵向看，编排建立在连接之上，效能横跨两者。横向看，安全决定每一步能不能做。四层之间存在天然张力：效能追求复用，安全要求隔离；编排追求自主推进，安全要求关键节点停下来等人确认。好的设计不止是让四层各自最优，而是在张力中找到适合具体场景的平衡。
模型在进化，很多今天需要精心编排的问题，明天可能被更强的推理能力自然消解。但这四类问题本身不会消失——只要你把概率模型放进生产系统，连接、编排、效能、安全就一定会以某种形式出现。
如何围绕自己的业务场景，把这套框架落地，就是你的 Harness。