2026年9月的一个普通工作日，以色列最大银行之一Bank Hapoalim的外汇转账系统悄然发生了一件事：一个AI智能体开始自动处理该行超过90%的跨境转账，只在需要人类判断时才将任务转交银行职员。这个名为Project Sentinel的系统，被设计来像一位经验丰富的银行家那样评估每一笔转账，但它从不“聊天”，从不“解释”，只做一件事：判断这笔转账是否合规、是否安全、应该放行还是拦截。
同一个月，另一个数字在AI工程社区引发了更大的震动。在测试Agent处理多轮真实客服任务的τ-bench基准中，GPT-4o单次调用可以完成约61%的零售任务。但当同一任务要求连续8次都成功——这正是生产环境的基本要求——可靠性骤降至约25%。换句话说，如果你的Agent需要连续完成8个步骤才能给客户一个完整的答复，那么四次里有三次会失败。
这两个数字放在一起，揭示了当前AI行业最深刻的张力：AI的能力上限已经高到足以挑战数学难题，但它在最基础的生产级自动化中的可靠性，仍然远远达不到“可依赖”的标准。
问题出在哪里？答案或许不在于模型本身不够聪明，而在于我们一直在用一种错误的方式使用它。
过去两年，行业的主流范式是把大模型当作一个“数字同事”——你给它一段Prompt，它回你一大段自然语言；你期望它像人一样理解意图、像人一样客套回应、像人一样在模糊中做出判断。但真实的软件工程根本不需要一个坐在屏幕对面唠嗑的同事。它需要的，是一个像数据库一样确定、令行禁止、可以直接嵌入 if 或 switch 语句的底层决策组件。
这，就是“机器原生AI”思潮的核心命题。
一、问题诊断——“像人一样工作”的三个结构性缺陷
缺陷一：RLHF让模型学会了“自信地犯错”
要理解当前AI在决策任务上的困境，必须回到RLHF（基于人类反馈的强化学习）的训练机制。
RLHF的初衷是让模型“有用、诚实、无害”。它的核心逻辑是用人类偏好作为奖励信号，引导模型生成人类喜欢的回答。这个逻辑在对话场景中有效，但它有一个几乎被行业系统性忽视的代价：模式丢弃。
剑桥大学研究者的工作给出了一个清晰的诊断框架。他们将“对齐税”重新定义为不只是任务准确率的下降，更包括“模型校准能力的严重退化，使模型变得过度自信、可靠性降低，输出多样性萎缩”。对齐技术会诱导模式坍塌，导致模型丧失表征不确定性、产生多样化输出的能力，而这些能力恰恰是用户信任和模型实际可用性的关键。
换句话说，RLHF训练出的模型学会了一种“社交策略”：给出最稳妥、最不会被人类挑剔的回答，而不是最准确、最反映内部置信度的回答。它学会了在不确定时假装确定，在模糊时选择最安全的中庸表述。这在聊天场景中或许无伤大雅，但在决策场景中，这是致命的。
这也是为什么当前最强大的模型会在“千禧年数学难题”上展现出惊人的推理能力，却会在最基础的分类、路由、评分任务上频繁出错。数学题的正确答案是唯一的，模型不需要在“讨人喜欢”和“说真话”之间做取舍。但决策任务不同：模型必须诚实地表达“我不确定”，而这种诚实恰恰是RLHF训练所惩罚的行为。
缺陷二：Function Calling是“在Prompt里求模型干活”
如果说RLHF的问题是训练目标错了，那么Function Calling的问题是接口设计错了。
Function Calling是当前Agent系统调用外部工具的标准机制：你把工具的名称、描述和参数定义塞进Prompt，模型在“决定”要调用某个工具时，输出一段结构化JSON。听起来很合理，但工程实践中问题重重。
DigitalOcean的一篇深度分析文章给出了系统性的诊断。文章指出：“Function-calling accuracy is not workflow reliability”——函数调用的准确率并不等于工作流的可靠性。在τ-bench中，GPT-4o的零售任务单次成功率为61%，但要求连续8次成功时，可靠性下降到约25%。文章进一步解释，问题不在于模型“不会调用工具”，而在于Agent运行在一个循环中——调用工具、读取结果、决策、再调用——面对的是不断变化的API、移动的状态、过期的凭证和可能带有敌意的输入。
更根本的问题在于接口设计本身。正如Diogo Almeida在访谈中所批评的：“开发者想控制模型调用某个接口，唯一的手段居然是在Prompt里像孙子一样求它‘请务必调用这个函数’。”这种设计的荒谬之处在于：一个本应是确定性的控制流决策——是否调用、调用哪个、以什么置信度调用——被外包给了模型在自然语言空间中的“理解”和“服从”。
缺陷三：上下文退化——不是窗口不够大，而是信号被噪音淹没
第三个结构性问题关于上下文管理。当前Agent系统的普遍做法是将所有相关历史、工具结果和指令塞入一个越来越长的Context窗口，期望模型在庞大的信息中“自行找到重点”。
但Chroma的研究给出了一个残酷的结论：他们测试了18个前沿模型，发现每一个都会随着输入长度的增加而性能下降。不是一部分，不是大多数，是全部。更关键的是，退化在远未达到标称窗口上限时就已经开始——一个拥有200K Token窗口的模型，可能在50K Token时就已经表现出显著退化。Chroma的研究还发现，退化在“针与问题的语义相似度低”时更快发生，而现实世界的查询很少与答案逐字匹配；干扰项会复合退化效应，且以非均匀方式分布。
对于Coding Agent而言，上下文退化是首要的失败模式。不是模型不够聪明，不是推理能力不足。模型足够聪明来解决一个问题，前提是它的上下文保持干净。问题在于上下文不会保持干净：Agent在搜索、探索和回溯过程中不断积累噪音，而这些噪音直接降低每一次后续输出的质量。
二、工程方案——“像基础设施一样可靠”的四个转变
诊断了问题，方案的方向也随之清晰。从“像人一样工作”到“像基础设施一样可靠”，需要四个层面的工程转变。
转变一：概率与确定的边界——让模型提案，让代码裁决
“像基础设施一样可靠”的第一原则，是明确划分概率性组件和确定性组件的职责边界。
Aaron Erickson曾提出了一个被越来越多生产系统验证的原则：“可靠性来自于将概率性组件与确定性边界相结合”。模型可以解读问题、检索证据、分类情境、建议行动。确定性系统负责执行行动、强制执行约束，并提供使整个循环可评估的遥测数据。
这一原则在学术研究中得到了正式化。一篇关于概率-确定控制边界的论文指出，在三个不同的应用系统（聊天机器人、自动化工作流、Oracle到PostgreSQL的迁移工具）中，虽然概率性任务各不相同，但共享同一个控制原则：“生成的提案在成为被接受的答案、被授权的行动或被验证的软件工件之前，必须跨越一个显式的确定性边界”。
Postgres Summit US 2026上的一个演讲将这一原则表述得更加直白：“大语言模型本质上是概率性的，这使得它们难以在生产环境中可靠运行。通过将确定性系统围绕模型放置，并用PostgreSQL管理流程状态、验证、评估和编排，我们可以约束这个随机核心，使整个系统更加可预测和可观测”。
对Harness工程的直接启示是：模型的输出不应被直接执行。模型的输出是“提案”，必须经过确定性代码的验证、授权和记录后才能成为“行动”。 这个验证层就是Harness的核心职责。金融AI系统Bretton的实践印证了这一点：他们的Agent Harness被设计为监管机构批准的层，正是因为它将模型的概率性输出封装在一个确定性、可审计的框架中。
转变二：原子化决策——从“大Prompt”到“可评测的微决策”
RLHF的问题在于训练目标与决策任务的需求不匹配，但还有一个工程层面的替代方案：不改变模型，改变我们使用模型的方式。
核心思路是将复杂的业务逻辑拆解为一系列原子化的决策。每个决策只回答一个明确的、可度量的、有确定答案的问题。不是“这个客户投诉应该如何处理”，而是“这条消息是否表达了紧迫性”“这个问题的类别是A还是B还是C”“这个请求的复杂度评分是0-10中的多少”。
这种拆解的价值在于：每个原子决策都具备了可评测性。当决策粒度足够细，开发者可以为每个决策设定独立的置信度阈值和回退策略。如果模型在“判断讽刺语气”这个维度上置信度低于阈值，系统可以将工单转交人工；如果模型在“判断是否紧急”上置信度高于0.95，系统可以直接路由到高优先级队列。
在技术层面，这一模式正在被Jev等“System 1模型”强化。Jev不生成文本，只返回结构化判断和校准概率。它支持三种原语：Choice（从选项中选择，返回每个选项的概率和整体置信度）、Score（按序数级别评分，返回连续分数和底层分布）、Noul（回答是/否问题，返回为真的概率）。这些原语直接映射到编程中最基础的控制结构：Choice映射到枚举switch语句，Noul映射到布尔if条件，Score映射到基于阈值的排序与过滤。
更重要的是，Jev可以在一次请求中并行回答同一状态上的多个问题，额外问题的响应时间几乎不变，成本仅来自额外问题的Token费用。这意味着“将任务拆解为一百个微决策”在工程上变得可行——不再需要为每个决策单独发起一次昂贵的LLM调用。
转变三：置信度门禁——让概率成为控制流的输入
传统Agent的决策是二元的：工具调用要么通过，要么失败。这种二元设计在简单场景中够用，但在需要分级审批的复杂工作流中，它丢失了最重要的信息：模型对某个决策的置信程度。
生产级Harness的设计正在转向置信度分级门禁。一个实用的策略是三分法：置信度高于0.8时直接执行主要行动；0.5到0.8之间执行保守行动并附加监控；低于0.5时激活基于规则的备用方案。
这不仅仅是一个工程技巧，它反映了对“可靠性”本质的重新理解。微软在Azure SRE Agent的设计中体现了同样的思路：系统持续观察遥测数据，理解资源拓扑和依赖关系，然后在人类治理下协助或执行修复动作。PalPay在Gemini Enterprise Agent Platform上构建的自主SRE Agent，将MTTR大幅降低，同时明确保持了“检测-分诊-缓解-报告”的全生命周期中的人类监督。
对Harness的启示是：门禁应该是连续的、分级的、策略驱动的，而非二元的。 Harness应维护一个从置信度到动作的映射策略，根据决策的风险等级动态调整阈值。高风险决策（影响超过一定金额、涉及不可逆操作、影响多个客户）需要更高的置信度阈值；低风险决策可以使用更低的阈值以提升效率。这种设计将安全约束从模型的“自觉”中解放出来，交由确定性的策略引擎执行。
转变四：记忆分层——从被动存储到主动索引
Almeida在最近访谈中提出了一个深刻的观察：当前Coding Agents被绑定在单一模型上，为了维持推理效率只能不断在同一上下文中追加内容，导致传统软件工程的状态管理、分层抽象和模块解耦“几乎都不复存在”。为什么无法把简单的子任务分发给轻量级Sub-agent？因为两者之间需要传递的状态过于庞大，传递成本甚至超过了处理任务本身。
这一问题的根源在于：当前的记忆架构本质上是被动的历史记录。对话历史、工具调用记录、文件修改记录被顺序存储，在需要时通过滑动窗口或摘要压缩来管理。但随着任务复杂度增加，这种被动记录模式迅速遇到瓶颈。
前沿Harness设计正在转向主动的语义化分层记忆。AG2的Harness架构将记忆拆解为多个可插拔层：MemoryStream作为追加式事件主干，所有事件（用户消息、模型响应、工具调用、结果）首先进入这里；AssemblyPolicy在每次LLM调用前重建上下文窗口，应用压缩和聚合，使Agent在上下文压力下保持可用；Knowledge层提供持久化的键值存储，在进程重启后仍然存活。
记忆分层研究进一步形式化了这一方向。MemoryOS将记忆分为短期、中期、长期三层，通过热度分数驱动的晋升机制在层间迁移，使“热/冷”边界成为一个显式的、动态维护的对象，而非固定的截断点。核心设计原则是：记忆的粒度应与决策的粒度对齐。 与其存储完整的对话历史和所有工具调用记录，Harness应为每个已完成的原子决策存储其输入状态、输出结果和置信度，并以语义标签索引。当新的决策点被激活时，Harness根据语义标签检索相关历史决策，而非将全部历史塞入Context。
三、行业验证——从实验到生产
金融行业：监管批准的AI Harness
金融行业是“像基础设施一样可靠”理念最严苛的试金石。Bretton AI的案例值得深入审视。他们的Agent Harness被设计为能够获得监管机构批准的层，核心设计原则包括：类型安全——每个操作都有明确的输入输出类型，区分成功、空输出和失败；来源追踪——检索到的上下文或生成的工件的来源被显式记录；授权上下文——副作用操作与主体、动作和审批状态绑定；幂等性——重试或重复事件不会创建重复的外部效果；版本可复现性——保留重现结果所需的Prompt、规则、模型和配置状态。
Bretton的设计哲学可以用一句话概括：监管机构不需要信任模型的“智能”，他们需要信任系统的“确定性”。 当每一个决策都可以被回溯到具体的输入、规则、模型版本和审批记录时，可审计性就不再是一个附加功能，而是系统架构的内在属性。
运维领域：从“监控”到“自主修复”
Site Reliability Engineering领域正在经历类似的转变。传统SRE的自动化是确定性的——基于规则的告警、固定的修复脚本、人工审批的变更流程。AI Agent的引入不是要替代这些确定性机制，而是要增强它们。
StackGen的Autonomous Operations Factory代表了这一方向：可靠性调查在启动时就已经加载了部署历史，部署在发布前会根据实时基础设施漂移进行门禁检查。系统的核心能力不是“让AI做运维”，而是“让AI增强运维的确定性”——将部署历史、基础设施状态、告警关联等分散的信息源在Agent的上下文中统一起来，使确定性的决策（是否发布、是否需要回滚）建立在更完整的信息基础上。
华为在金融AI规模化难题的讨论中给出了一个精准的概括：“与传统软件不同，智能体的输出具有一定的不确定性，一次成功的任务执行也不能证明它能够在成千上万次调用中始终保持同样的准确性和稳定性。”这正是“像基础设施一样可靠”所面对的核心挑战：可靠性不是关于单次成功的概率，而是关于在成千上万次调用中保持稳定性能的工程能力。
结语：AI退居幕后，才是它真正发挥价值的时刻
回到开头的问题：为什么AI明明足够聪明，却在最基础的自动化工作中频繁掉链子？
答案现在很清楚了。问题不在于模型的能力上限，而在于我们一直在用一种错误的方式部署它。我们把概率性的文本生成器当作确定性的决策引擎来使用，把自然语言的模糊性当作接口的灵活性来欢迎，把模型的“社交策略”当作真正的置信度来信任。
“像基础设施一样可靠”意味着：AI不再试图成为你的同事，而是成为你的数据库、你的消息队列、你的类型系统。它不“理解”你，它执行你定义的操作。它不“判断”对错，它返回校准过的概率，而由你的代码来做出最终的决定。它不“记住”一切，它只保留你的系统状态所需要的最小必要信息。
这听起来或许不那么令人兴奋。没有人会为“AI帮我正确地路由了一封邮件”而惊叹。但正如Diogo Almeida在访谈中所指出的，全人类陪AI聊天的价值，不如程序员一个持续运行的for循环。当AI退居幕后，成为软件架构中一个安静、可靠、可预测的组件时，它才能真正释放其改变经济结构的潜力。
从“让模型像人一样工作”到“让模型像基础设施一样可靠”，这不仅是技术的转向，更是一种工程哲学的成熟。它承认了一个朴素的事实：在绝大多数需要AI创造经济价值的场景中，我们需要的不是智能本身，而是被可靠封装、可编程、可审计的智能。
