财务场景的智能体，卡在「能做」和「能做主」之间
把智能体放进财务流程，争的从来不是它能不能读发票、能不能匹配单据。这些能力在自动化时代就已经被解决得差不多了。真正难的是另一件事：一个动作由它自己发起、自己执行，出了问题谁承担。
9 月 9 日，总部在里昂与麦迪逊的 Esker 发布了 Synergy Agentic Framework，思路是把智能体放进既有的财务流程与治理结构里，而不是在旁边再摆一套独立的 AI 工具。它建在已有的 Synergy AI 能力和事务型平台之上，横跨 Source-to-Pay 与 Order-to-Cash 这两条主链路。
框架由三项能力组成
官方的结构是 Act、Talk、Connect 三项，下面垫着一层共同底座，包含上下文、智能、控制与保证四个部分。
Act 负责自主执行。一组被称为 Business Agents 的智能体承接重复性动作，超出预定义边界或者需要判断的情形，升级给人。
Talk 是对话式财务。用户可以用自然语言提出请求，框架把请求接回相应的上下文、流程或者某个 Business Agent，可以取回信息、引导完成录入，也可以执行一个受治理的动作。这个方向反过来也成立：当需要人工审批、澄清或确认时，平台会主动找人。
Business Agents 具体接手哪些动作
按照官方列举的范围，Business Agents 可以在 Source-to-Pay 与 Order-to-Cash 上处理这些事：识别发票异常、路由审批、给催收排序、评估信用风险、支持现金核销、处理索赔，以及协助客服团队回应问询。
把这些动作排一下会发现一个共同点：它们都发生在「规则能覆盖大部分情形，但总有一小部分要人来判断」的区间。规则完全能覆盖的部分，流程引擎早就做了；完全靠判断的部分，智能体也接不住。剩下这段中间地带，才是它的实际战场。
Connect 想开放的是能力，不是系统
第三项 Connect 值得单独说。它要把选定的财务能力开放给其他人、其他系统以及外部智能体。技术上通过 API 以及 MCP、A2A 等正在成形的标准连接。
关键差别在于开放的粒度。Esker 的表述是暴露受控能力，同时把身份、权限、业务策略以及最终产生的财务动作留在自有治理层内。换句话说，外部智能体拿到的是「可以发起某类动作」的资格，而不是「能直接写进财务系统」的通道。
这个选择在架构上更稳妥，但它也带来一个需要客户自己想清楚的问题：治理边界的定义权在厂商手里。哪些动作算可自主、哪些必须人工确认、越界的阈值设在哪里，这些参数最终由框架提供方来划定。客户在采购时真正要问的，是这套边界能不能按自己的风险偏好调整。
把概率性的判断与确定性的执行分开
Esker 的首席产品与技术官 Jean-Jacques Bérard 有一句话被放进官方表述里：智能体的价值不来自模型本身，而来自把合适的智能与可信的事务上下文、业务规则和受治理的执行结合起来。
这句话指向一个技术上的分界。模型的输出是概率性的，财务的动作必须是确定性的——一笔付款要么执行要么不执行，不存在「大概付了 80%」。这类框架的共同做法，是让模型负责判断与编排，让既有的规则与流程引擎负责落地执行，中间用权限和审批做闸门。
听起来是常识，但工程上并不好做。分歧通常出现在边界条件：当模型给出一个低置信度但方向正确的建议，是让它带着标记执行、还是直接升级给人。不同产品的默认答案不一样，而这个默认值会直接影响人工介入率。
那几组 90%、40% 和 3 倍，该怎么读
公开材料里有三组显眼的数字：客户反馈的发票免人工处理比例超过 90%、应收账款周转天数缩短超过 40%、审批与争议处理以及订单处理的提速在 3 倍以上。
这里有一个容易被略过的表述细节。Esker 明确把这批结果归给既有的自动化部署，也就是客户在采用 Synergy AI 与既有平台之后的累计反馈，而不是新框架上线后的成绩。官方把新框架定位成「下一步」——把自动化从单个任务推进到更长的受治理执行序列。
把归因对象拆开，是读这类发布时最实用的一条习惯。数字本身来自已经跑了许久的客户场景，可信度相对高；但它们回答的是「这套平台在成熟部署里能做到什么」，不是「新框架能把指标再推高多少」。后者需要等新框架的实际落地口径。
还有一层需要留意：这些是客户自报口径，行业里不同客户的数据基础、单据标准化程度差别很大，同一组百分比在不同规模、不同成熟度的组织之间可比性有限。它们更适合用来判断方向，而不是用来做采购测算的输入。
这类框架真正的考验在哪
把智能体放进治理层，而不是并列成一个新工具，方向上是稳健的。它避免了财务部门同时维护两套并行的审批路径——那几乎必然导致口径分裂。
考验则集中在两处。一处是边界定义的可调性，客户能不能按自己的合规要求重新划分「可自主」与「必须人工」。另一处是责任归属：当一个由智能体发起、由流程引擎执行的付款出现差错，追责链条能不能完整回放出来。这要求每一步判断与每一次人工确认都被留痕，而不是只记录最终动作。
公开材料没有披露这套框架在客户侧的平均人工介入率、回放粒度，也未见第三方对执行准确性的独立评估。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
把审批留给人，代价落在哪里
框架反复强调「升级给人」，这是稳妥的设计，但代价容易被低估。每一个升级点都会占用人的注意力，而当升级频率上来之后，审批就可能从「判断」退化成「划过」。这正是过去几年告警与控制台普遍遇到的问题——不是没人负责，而是负责的人被信息量压到只能做成本最低的确认。
所以这类产品的实际效果，很大程度上取决于升级阈值怎么设定。设得太松，风险动作容易溜过去；设得太紧，人又会被淹没。公开材料没有给出这方面的默认策略与可调范围。
一个更朴素的判断标准
财务是所有企业场景里对「错了要付钱」最敏感的一处。因此评估这类框架时，有一个比功能清单更朴素的标准：把它当成一位新入职的财务同事来考察——它的权限给到了哪一级、它做决定时需要谁签字、它做错之后能不能查清楚发生了什么。
功能列表回答的是「它能做什么」，上面三个问题回答的才是「它敢不敢被用在真金白银上」。前者容易演示，后者只能靠部署之后的时间来验证。