看了一些关于工业现场的 Agent 的文章。有一个观察，发现只要把Agent 放进工业现场,讨论就很容易从"它能不能判断"滑向"它能不能直接控制"。对一个从“判断”到“自动控制”的中间过程却鲜有描述。

这篇文章想理清的就是：针对工业Agent，从判断到自动控制中间到底还要做什么。

真正的问题不是它能不能算

使用烧结矿碱度控制Agent举例。想让智能体(Agent)帮你稳定烧结矿碱度(R=CaO/SiO₂)。它读到了当前配料单、最新的原料成分、烧结机台速、混合料水分、风箱温度、最新的烧结矿成分检化验值,看到模型预测出来的碱度可能偏低,于是判断:如果不干预,下一批烧结矿的碱度可能落在目标范围之外。它给出一个动作——把石灰石配比上调 0.25%。

讨论到这里,常见的想法是顺势往下推一步:Agent已经完成判断,下一步就是将这个0.25%的石灰石上调指令，下发给PLC，完成自动调节这个目标。

但问题就出在这一步。

烧结现场真正难的,不是让Agent给出一个看起来合理的动作,而是判断这个动作到底能不能进入现场执行系统。因为，它在执行动作之前，需要首先回答：能不能改变量,能改哪些变量,单次最多改多少,连续改几次以后必须停下来,异常工况下还能不能执行。

这有点像装修。设计师可以告诉你这面墙适合打掉,客厅会更通透,但真正动锤子之前,你不能只看设计图，你要确认这是不是承重墙,物业让不让动,施工队有没有资质,改完以后谁来验收。否则设计建议越漂亮,现场风险越大。Agent 也是一样:它给建议是一回事,它能不能执行,是另一回事。

只给建议,还不叫执行系统

如果 Agent 只是告诉操作员"当前碱度可能偏低,建议提高熔剂配比",那它仍然停留在辅助决策层。这层的价值是可以把原来靠经验判断的事情提前暴露出来,也可以把低频化验、在线检测、过程变量和预测模型放进同一张图里,让人更快看出趋势。但这种模式有一个天然的边界，它只负责说出"可能发生什么"和"建议怎么做"。并不具体真的执行。

真正进入执行层以后,面临的问题就变了。Agent不能只对自己要求建议是否合理,还要问给出的这条建议有没有资格变成动作。同样是提高石灰石配比 0.25%的建议,烧结机在不同的状态下，理解就不会相同。在稳态下可能是一个小幅补偿动作;但在原料突变、料流异常、烧结机状态不稳的时候,考虑的就需要更加复杂。这时碱度偏低未必是配料误差造成的,也可能是检测滞后、物料流转错位、工况切换或短时扰动带来的表观结果。如果Agent不能自主的区分这些状态,把一个不能下发的建议当成现场命令。

这不是智能化,这是把风险自动化。

执行链要先把边界说清楚

因此，烧结 Agent 真正进入现场之前,前面需要补上一条完整的执行链。这条执行链至少要回答三个问题:变量边界、幅度边界、状态边界。

变量边界说的是:Agent 到底能动什么。它只允许调整熔剂配比,还是也能给固燃比、水分、机速、料层厚度提建议?哪些变量允许自动写入,哪些变量只能提示人工确认?这一条没说清楚,Agent就会从一个配料建议工具,慢慢变成一个什么都想碰的现场控制者。

幅度边界说的是:每次能动多少。单次最大调整多少,单位时间累计最大调整多少,连续调整几次后必须转人工确认。

状态边界说的是:什么时候可以自动执行,什么时候只能建议,什么时候必须报警。稳态下允许小幅自动补偿,过渡态下只能建议,异常态下必须转人工处理。这条边界不清楚,Agent 就会在最不该自信的时候自信。

这三条边界合起来,才是执行链真正的价值。它不是为了让Agent 更自由,而是为了让 Agent 的自由被限制在可验证的范围内。

权限不能是一把长期钥匙

在常见的系统设计里,权限被理解成账号权限，谁能登录,谁能修改参数,谁能下发设定值。但如果 Agent 参与执行,这种理解就不够了。Agent 不应该拿到一把长期有效的钥匙,然后随时根据自己的判断去改现场参数,更合理的方式,是把每一次执行都收成一张一次性凭证。

这条控制令必须写清楚:这一次调哪个变量,调多少,为什么调,在哪个时间窗口内有效,触发条件是什么,边界校验是否通过,什么情况下自动撤销,什么情况下转人工确认。

这有点像餐馆经理。经理可以根据客流变化临时调整后厨人手,但他不能因为今天客人多,就随便改菜谱、改采购标准、改收银规则。每一类动作都有自己的权限边界,有些可以现场决定,有些必须老板确认,有些根本不能临时改。烧结现场的 Agent 也是一样，它可以参与判断,但不能把所有判断都自动升级成执行权。

反馈不是看结果好不好

谈闭环时,闭环很容易被理解成"结果好了就继续,结果不好就修正"。烧结过程有明显的时滞:配料端动作下去以后,要经过混合、布料、烧结、冷却、取样、检测,才能真正反映到成品指标上。如果系统只看最终碱度,就会把中间的各种扰动都混在一起,最后很难判断这次调节到底有没有效果。

所以反馈链不能只记录结果,还要记录过程。一次 Agent 调节之后,系统至少要知道几件事:动作有没有真正下发,现场有没有执行到位,执行期间工况有没有变化,后续预测值有没有按预期回归,最终检测结果和预测是否一致。如果某一环断了,系统不能简单地说"模型错了",也不能简单地说"操作错了",它要能把问题定位到链条中的具体某一段。否则,所谓闭环就只是把一个动作扔出去,再等一个模糊的结果回来。

审计不是事后留痕,而是执行条件的一部分

如果 Agent 参与烧结控制,审计不能只做成事后报表。事后报表当然需要,但它解决的是"出了问题以后怎么追溯"。可靠的系统,应该在执行之前就把审计条件嵌进去——一条控制建议要想变成控制动作,它必须先通过这些条件:来源是否清楚,模型版本是否明确,输入数据是否完整,边界校验是否通过,是否处于允许自动执行的工况,是否超过累计调整次数,是否需要人工确认。这个思路就是上一篇“从过程确认到结果确认“的思路转变。

这就像家里装电器。不是等电器烧了以后再去查安装记录,而是在安装之前就确认电压、线路、功率、插座、漏保是否满足要求——满足条件才能装,不满足条件就不能装。工业系统里的审计也应该这样:它不是写给别人看的记录,而是用来判断"这次动作有没有资格发生"。

Agent 的位置应该往后退一点

这样一路想下来,应该把烧结 Agent 放在一个更克制的位置上。它不应该站在现场系统的最前面,像一个新的操作员一样直接发号施令;它更应该站在目标、模型、规则和执行系统之间,把复杂信息整理成一个受约束的控制建议,再交给执行链去校验、下发、反馈和审计。

这样理解以后,Agent 的价值反而更清楚。它不是取代DCS(Distributed Control System,集散控制系统),也不是绕过 PLC(Programmable Logic Controller,可编程逻辑控制器),更不是把原来的控制系统推倒重来。它要做的,是把原来分散在经验、报表、模型和人工判断里的信息,组织成一条可以被验证的执行建议。能不能执行,不由 Agent 自己说了算。

执行链说了算。

烧结系统缺的不是更大胆的 AI

所以不太推荐把烧结 Agent 写成"一个能直接管控现场的 AI"。这种说法听起来更有冲击力,但它会模糊一个关键问题:工业现场真正需要的,不是一个更大胆的智能体,而是一个更受约束、更可验证、更容易追责的执行者。

如果目标不清楚,它会把局部优化当成全局优化;如果边界不清楚,它会把建议扩大成控制权;如果权限不清楚,它会把一次判断变成长期钥匙;如果反馈不清楚,它会把结果波动误判成动作有效或无效;如果审计不清楚,它会在出问题之后说不清当时为什么这么做。

这也是为什么说,讨论烧结 Agent 时,不应该从"它有多聪明"开始,而应该从"它被允许做什么"开始。找一个你正在设计的智能化功能,把它拆成五句话:目标是什么,允许动什么,最大能动多少,什么状态下能自动执行,失败后谁接管。这五句话写不清楚,Agent就不应该进入执行层。