其实我曾经很苦恼一个问题在agent产品中模型尤其是核心环节的模型究竟是应该让其更自由发挥好还是说想尽办法加上条条框框让其做出最稳定的输出好呢。其实这是个挺无病呻吟的问题因为在agent产品中对模型的应用本来就是确定性和不确定性具备的——我们希望模型能灵活地、聪明地处理各种来源、各种说辞、各种业务种类的信息然后通过外挂工程或者调用工具来实现稳定的输出。这是彼此间犬牙交错的设计逻辑而非是单一的、死板教条的达成我们稳定的需求。但是我总认为这样恰恰是限制了模型的潜力。我一直认为模型最大的魅力就在于其不确定性。我们希望能最大程度使用模型的算力资源却又试图把控这种不确定的存在。我既希望agent产品达成稳定输出又希望模型能发挥“创意”在交互端带来惊喜。当然我希望模型带来惊喜这好像也是一种稳定。当然这些问题好像在我还任职于黄厂时候并不存在这些考虑因为当时我们解决的不是不确定性问题——其实也是——而是设计的流程中模型根本不按照我们的思路去思考和执行。在标准的使用场景下产品运作和输出还算是稳定但是只要用户的说辞稍微改变就立刻“原形毕露”。也许大家会说换更好的基座模型不就行了。现在市面上成功的agent产品不都是离不开优秀的底座模型。放在当时我们却不存在这样的选择黄厂自研模型的逻辑和编程能力客观来说还是不错的。但是在语义理解最基础的方向不尽人意而备选模型我们当时只能选dsv3。至于说为什么不选择r1且不说性能如何r1的思考实在是太长了这还只是模型思考的时间。agent产品还有一个特点就是结果的准确率往往会掩盖过程的失控。只要agent逻辑中模型有一步调用工程错误往往就会导致一大串连锁灾难。不管是添加多么严谨的自校验机制过程失控始终是一个隐患。从这个角度看模型太过自由肯定是不能接受的成本。在基座模型受限的情况下不管是大量训练还是调整参数都不是解决问题的救赎之道。今年的模型能力相比较去年真的算是今非昔比今时不同往日。我时常想如果我们能在模型选型中确认更好的基座模型会不会让产品更优秀呢。但是哪怕是如今的模型依然是存在错误概率的依然需要充分的外部工程矫正输出的。前几天读了一篇南大8月份的论文给我带来一些启发。当然我不是穿越者不能像金刚狼一样穿越回过去拯救未来。但是不让当时候诸葛亮总不能不让事后反思吧。论文把[领域本体类型化推理函数]封装成agent唯一可以调用的内核简称oak让react框架的智能体从自由推理变成经过在经过教研的语义空间里执行。说点人话就是把任务相关的[概念关系可执行操作]打包成一个本体内核让其成为agent与数据之间的唯一通道。在oak中有两个核心小巧思第一个是把schema交给专门负责逻辑推理功能的环节进行全套逻辑校验拒绝“看着说得通”的问题做到逻辑上严格成立。第二个就是把大模型的思考的修复意见经过一套四步走的结构流水线明确得到最终修改意见。把大模型的反思内容变成可以按部就班执行的修改指令实现闭环迭代把软性业务要求编程必须执行的系统硬性规则。最终形成这样一套逻辑模型还是正常思考不是在大模型输出上新增约束条件而是在agent工程角度多一道结构化逻辑审核。这样一来在后续阶段agent就会被约束成只能使用修改后的条件和函数。这样一来模型的思考能力没有被限制在纠错思考过程中oak实现了在agent中新增了按照错误清单查缺补漏的环节。这个方案的思路仍然是在agent层面做文章有在很大程度上保留了ai思考、反思、纠错的能力。这个架构未来普及程度如何不好预测但是给我带来的思考水agent中工具层等其他单元或许从来不是限制了模型的能力。模型的cot中值得推敲的内容很多缺少的是能将其高效利用的新的工程思路。或许真正优秀的ai从业者、研究者从来不纠结是约束还是放纵模型的能力发挥而是对其每一个环节发掘机会加以利用这才是最大化使用ai的能力把。