人工智能

如何让人工智能代理在关键系统中变得可预测?

Stack Overflow Blog 建议将语言模型限制在一个非确定性节点中,并将系统的其余部分交给可测试的普通代码。该方法包括固定流程图、结构化输出、独立验证、人工批准,以及记录每项决策且不可删除的日志。

2026-10-07
1 分钟阅读
1 浏览量
certi.news Editorial Team
如何让人工智能代理在关键系统中变得可预测?

在处理资金转账、医疗保健或基础设施的系统中,人工智能代理仅在大多数情况下成功是不够的。由六个等级组成的语言模型生产系统运行成熟度模型的第一级,其核心理念是将模型限制在单个节点内,使其周围的部分保持为可以测试、审查和审计的普通代码。

该材料将这一方法称为“确定性层”:系统保留模型对复杂输入进行判断的能力,但阻止模型直接控制业务状态或执行敏感操作。

代理只提出建议,不执行操作

代理作为一个纯函数运行,将上下文转换为建议决策。它会生成决策标识符、所需权限、建议的变更、置信度、路由路径、理由和证据,但不会改变业务状态。随后,结果会传递给一个独立组件,材料称之为substrate,只有在获得所需批准后,该组件才负责应用结果。

这种分离为系统带来三项实际特性:无需模拟外部世界即可测试代理,将错误输出的影响缩小为可以拒绝的建议,并防止代理之间出现隐藏的副作用链。这样一来,可审计的问题就变成:模型提出了什么建议、谁批准了它,以及实际应用了什么?

固定流程图取代自由循环

材料建议为每项能力设置固定流程图,而不是让 ReAct 模型每次自行决定下一步。根据示例,请求依次经过决策输入、输入检查和上下文加载节点,然后进入单个语言推理节点,之后是输出防护栏和验证、可选仲裁、置信度汇总、路由、建议准备,以及记忆和决策日志写入节点。

这种结构使执行路径预先已知,限制执行时间和成本,并允许分别测试每个节点。其中,非确定性节点是llm_decision。它接收结构化输入并生成结构化输出,而专用代码负责验证允许的值、模式匹配和业务规则。

结构化输出不等于决策正确

材料警告,不要依赖自由文本,然后再尝试从中提取决策。替代方案是使用 JSON 模式、工具调用或受语法规则约束的生成,然后验证结果;如果不匹配则重试,同时限制重试次数,并采用封闭式失败,而不是将猜测传递给后续阶段。

但这一措施只能控制输出的形式,不能保证判断正确。一个 JSON 对象在语法上可能是正确的,却包含错误决策。因此,业务规则验证、评估和独立的置信度信号必须保留在后续层中。

置信度、升级处理和不可删除的日志

置信度由模型信号、验证结果,以及在对敏感决策进行抽样时对第二个模型的审查结果共同构成。随后,系统会将决策路由至自动执行、建议人工审查、强制人工审查或拒绝决策。材料强调,置信度不应是由代理自行设定的字段,而应由独立信号计算得出;阈值应从保守设置开始,只有在数据证明其安全后才降低。

还应将每项决策记录在额外的、不可删除的日志中,其中包括模型和提示词的版本、决策输入的摘要、决策、置信度以及路由路径。更正不会修改此前的日志,而是作为指向其所替代决策的新日志添加。材料建议对敏感输入存储哈希,而不是原始数据,并且即使在压力下也不能放弃写入,因为日志是主要参考依据,而不仅仅是监控数据。

何时允许使用迭代循环?

该方法并不完全拒绝 ReAct 循环,但将其限制在步骤数量和顺序取决于模型在搜索过程中发现的内容的情形。即使使用循环,也必须明确设置迭代上限、为每项能力规定允许使用的工具、记录每一步,并将输出重新交由同样的防护栏、验证、置信度和路由机制处理。如果在达到上限前仍未得出结果,路径应转为人工审查,而不是进入无休止的循环。

编辑解读:这里真正的变化不是选择更好的模型,而是将信任中心从“代理自主性”转移到围绕代理的边界工程。这种设计不会自动解决判断正确性或置信度校准问题,但能让故障得到隔离、复现和审查。因此,它适合作为高后果系统的基础规则,而不是替代持续评估或针对每项能力进行专业验证。

新闻来源
Stack Overflow Blog
查看原始来源 ↗
c
作者

certi.news Editorial Team

同一分类

你可能还喜欢

查看所有新闻