财务 AI 代理必须展示计算过程

Francesco Galletta 和 Felippe Felisola Caso 希望人们不要再把财务分析当成与电子表格聊天。两人都在 Monzo 从事金融服务数据工作，Caso 负责为内部数据团队打造 AI 工具。他们用个人案例开展工作坊，并非代表 Monzo 展示产品。

Caso 说，自己学习电气工程后进入数据领域，曾在初创公司和大型企业工作。在 Monzo，他主要通过内部开发的 AI 方案帮助数据团队提高工作效率。

Caso 说，团队以实际影响衡量 AI 采用：如果不能带来具体业务价值，消耗更多 token 本身并不是目标。工作之外，Galletta 也尝试用 AI 处理自己真正需要解决的个人问题。

Galletta 认为，财务分析的瓶颈已不只是快速产出答案。更难的是，让必须根据答案行动的人相信它，尤其当问题涉及金钱时。

Galletta 对“财务分析师”的定义很宽，从投资机构和银行的研究一直涵盖到个人理财。无论哪种情况，重要的是系统如何把工作与作决定的人联系起来。

测试、计划、评估和运行记录都有助于建立信任，但它们只是组成部分，并不等于完整设计。工作坊讨论的是模型外围系统应该遵循什么原则，才能让用户委派工作，同时不必盲信不透明的结果。

第一项原则是与模型对问题形成共同理解；第二项是一致性，让计算来自代码，而不是模型即兴心算。证据把结果与来源连接起来，责任机制将重要选择留给人，验证则引入独立视角。

Galletta 说，即便同时运行一百个代理，责任仍在人身上。他把能随用户共同改进的系统，与用户只管投入问题、寄望得到好结果的黑箱作了对比。

讲者强调，这只是他们在若干场景中使用过的一种方法，并非适用于所有问题的标准答案。工作坊希望参与者亲自体验和质疑这些设计，而不是只看一份技术清单。

案例来自 Galletta 自己的婚礼预算。看似简单的计算会变复杂：每人餐费只是几项变动成本之一，宾客人数也可能变化。参与者也可以把相同方法用于其他财务问题。

Galletta 解释，每桌或每人餐费并不能代表全部开销，还有其他浮动费用。这个案例之所以容易理解，正是因为看似简单的总额取决于多个可能独立变化的假设。

工作坊代码库包含完整的婚礼示例、演示用代理框架，以及供参与者开发自己变体的空间。讲者说，这个示例刻意用于展示原则，并不是打磨完善的生产软件。

这些原则彼此衔接：先形成共同计划，再让可重复步骤保持一致、展示证据、保留人的控制权，并从另一个方向检查结果。Galletta 提醒，完全依赖黑箱和要求逐行审查每项改动，都不现实。

准备好的示例展示完成后的计划，空白界面则允许参与者从自己的问题开始。Galletta 说，界面是体验代理行为的方式，工作坊的重点并不是视觉设计。

第一个练习从空白聊天窗口和一个财务目标开始。模型对某个术语的一般理解，可能与用户在具体家庭或机构中的意思不同；因此系统应鼓励提问和纠正，而不是假定双方已经理解一致。

规划阶段，代理的任务是询问所需信息、质疑缺失的假设，并帮助用户把问题说清楚。如果系统只是同意模糊指令并立即执行，结果的波动就会更大。

Galletta 描述了三笔婚礼款项：第一笔为 6,000 美元，第二笔金额未定，最后一笔支付余款。有些支出固定，但宾客人数会影响按人计算的费用。他想知道自己能否按时支付。

他又补充说，自己没有储蓄，母亲可能资助约 5,000，每位宾客约花费 150，花费 500 的还有鲜花。他故意把信息说得零散，迫使代理区分已知输入、不确定事项和缺失信息，而不是把模糊请求当成完整规格。

预填案例省略了多轮澄清。接受计划后，界面显示彼此相连的决策步骤，并标注信息是用户提供、代理提出，还是仍需作出决定。

Galletta 把共同上下文比作人的知识与模型知识之间的重叠部分。建立这部分重叠需要反复沟通，但能让系统更好地判断哪些因素重要。

访谈问题本身来自外围系统中的指令。演示中，将鼠标移到某项原则上，可以突出显示对应计划和节点，让设计过程可见，而不必让用户猜测聊天回复是如何产生的。

打开某个步骤，可以查看模型为什么加入它，以及根据用户措辞作出了哪些假设。用户能针对该步骤质疑假设。Galletta 将其与漫长的线性对话对比：早先的决定可能淹没在上下文中，最终用户只能重新开始。

界面同时展示建议计划以及各项决定之间的联系。由于计划被拆成节点，用户可以单独检查一项假设，不必让每次纠正都变成一场全局对话。

形成共同计划后，就要考虑一致性。其中有些步骤是计算：相同输入应该得到相同结果，因此系统应把它们实现为代码。Galletta 说，聊天窗口中的公式即使排版漂亮，后面的答案也可能明显错误。

一位听众说，财务结果第一次看起来可能合理，但重复相同请求时又会变化。讲者以此说明，灵活的语言理解与受控的计算之间需要更清晰的边界。

Caso 区分了指令和保证。即使告诉代理遵循许多规则，执行仍取决于概率模型；专门设计的系统可以结合模型的灵活性，并在需要控制结果的环节使用确定性的行为。

一名听众问，模型写出来的代码与直接在聊天中计算有什么不同。Galletta 提到可信赖的库、模块化代码，以及单元测试和端到端测试。区别不在于生成的代码天然正确，而在于它可以按照软件工程方法测试和复用。

讲者区分了快速搭建的工作坊演示和生产实现。他们认为，两者都能采用结合模型灵活性与确定性组件的原则，但生产工程还需要相应的测试与设计。

Galletta 曾让代理分类每月支出、退款和费用，却发现重复运行的结果略有不同。他花了时间和钱让代理重现之前已经做对的工作。他更愿意写一次脚本，以后每次需要相同计算时直接运行。

模型仍可选择合适的工具，但外围系统应将算术交给代码，而不是逐 token 即兴生成。否则，每个新会话都可能为已有可靠答案的问题重新发明一套实现。

婚礼预算图展示了哪些节点需要代码、测试用例和示例。Galletta 还希望界面展示代码版本：如果计算方法发生变化，重复同一流程的用户应该看到结果可能不再能直接比较。

函数名称即使不变，内部计算也可能已经不同。系统应展示版本变化，避免用户以为重复的是相同流程，却悄悄使用了另一种方法。

讲者邀请参与者打开某个步骤，查看代码并运行测试。系统应该引导这些检查，而不是每次都依赖用户记住某项计算需要代码或某项测试的存在。测试在环境中运行，不需要模型再“思考”一遍。

代码库中的另一份指南说明如何围绕相同原则搭建类似系统。讲者把它称为“编写指令的指令”：构建者可以选择实现方式，但应明确每个组件要完成什么。

一名参与者把这种方法与规格驱动开发比较。Caso 说，婚礼计划变化时分析也会变化，因此系统把原本可能是一整份长规格的内容拆成结构化部分，并通过工作流呈现。保存一份定义来源的原则仍然适用。

从数据团队的角度看，指标和维度的定义会变，源数据与背景也会变。系统必须识别这些变化并帮助双方保持一致，而不是每次假设改变都要求用户重新描述整个问题。

底层保存的材料起着类似规格文档的作用：记录系统正在构建什么。区别在于，演示将这些定义呈现为相连的工作流步骤，而不只依赖一份长文档。

讲者建议故意修改一项计算，看看测试能否发现问题。在示例中，如果修改破坏了该步骤的检查，系统就应阻止分析继续得出结论。

证据意味着能够说明数字从何而来，以及为什么据此作出决定。并非所有输入的地位都相同：金融文件中的事实、对聊天内容的解释，以及模型推断出的假设，不应该使用相同标签。

即便看似确定的宾客人数，也可能因为有人多邀请了几位客人而改变。如果假设错误、来源又不可见，整份预算都可能出错，却没人知道应该纠正哪个输入。模型需要系统帮助，才能区分估计和确定事实。

讲者建议根据来源标记：聊天中的非结构化表述需要解释，模型从记忆中提取的信息属于假设，提交的银行账单则是实际交易的证据。Galletta 将其比作分析前认真标注数据集。

证据链还必须覆盖计算本身。Galletta 回忆，一份共享主表中认定合理的数值范围发生了变化；同事不知道文件已变，虽然输入相同，却得到错误结果。代码变化也可能造成同样的盲区。

在演示中，点击带下划线的数字，就能高亮显示其来源以及依赖它的步骤。聊天中的更正既可以向前追踪到后续计算，也能向后追踪到提供该信息的人。其他财务系统还可能把数据追踪到连接器或数据供应商。

Galletta 邀请用户输入一项更正，再点击发生变化的数值。关键在于用户能追踪修改后的输入，并理解它为何影响下游计算。

一位听众说，自己经常想知道代理生成的演示文稿中的数字从何而来。Galletta 也遇到过类似情况：制作幻灯片的代理把一次修改请求中的示例反复放进整份演示，之后高层问他这个数字的来源。

责任机制建立在证据之上。讲者认为，无论使用多少个代理，人仍然要为结果负责。能够检查过程，有助于人解释自己的决定，而不是只说答案是模型给出的。

交付答案的人需要承担答案在现实中的后果，代理则不会。因此讲者把检查和审查机制视为对仍需负责的人的支持。

这并不意味着要批准每一项细小改动。一位参与者介绍，他会先审查任务集合，让代理执行，再审查结果。Galletta 认为，有意设置的关卡应聚焦重要判断和歧义；持续打断用户处理低价值事项只会增加工作。

有用的审查关卡应当提供高信号：影响结果的选择需要停下来检查，而不是每个小动作前都要求批准。听众提出先审任务计划、再审完成结果，就是这种区分的例子。

合适的关卡取决于具体用途。代理可以准备三种财务情景，但用户应在决策前并排比较。对于代码，测试可以提供有用证据，不必让人逐项批准每次计算。

这个示例不会从银行账户转移资金；人负责审查分析并决定每月储蓄多少。最终决定就是一个关卡，不过讲者也承认，演示还可以加入更多责任机制。

在婚礼示例中，一笔资助恰好在第三次付款当天到账，就带来了重要的时间问题。界面会记录决定是代理假定的还是用户修改的，并展示讨论分支如何重新并入整体计划。

用户之后可以修改宾客人数，查看其对计划的影响。Galletta 希望人们能够调整方向而不丢失整份分析：在普通聊天中，一句偶然说的话就可能改变工作方向，而且很难只撤回那一句、保留其余内容。

如果用户把宾客人数改成至少 150 人，系统就可以重新评估计划，并提示这一输入如何影响后续步骤。Galletta 强调，要有意识地设计反馈，而不是假设更正会自动按预期传播。

演示还允许用户把旁支问题放进单独分支。讲者希望用户能决定旁支对话是否影响主计划，而不是让每个问题都永久进入上下文。反馈机制应符合人们实际工作的方式。

验证增加另一双眼睛，但不会转移责任。Galletta 说，审查本身也可能成为负担：同事交来一份看似合理的结果，审查者却要负责找出所有错误。额外视角是给决策者的信息，而不是逃避责任的方法。

有经验的财务人员通常只需检查几个有代表性的单元格，而不必重做整张表。比如，异常庞大的营销总额就会促使他们进一步检查。重点是为合理答案增加一个独立参照。

有人问到已知正确的示例。Galletta 认为，它们能建立有用的基准，却也可能带有与原工作相同的选择偏差。查看相邻领域或独立来源，可能发现所有选定示例都漏掉的错误。

他回忆自己曾制作一张商业智能仪表板，查询和结果在他看来都合理；另一团队的业务人员却立刻看出数字不可能成立，因为它与该团队已知的信息矛盾。不同经验补上了缺失的检查。

讲者把这种快速判断描述为利用领域经验中的细小线索。模型的一般模式可能忽略某个对特定机构影响很大的 5% 差异。系统需要反馈机制，让用户指出看似合理的结果何时不符合自己的领域。

答案可能看起来大致正确，却不符合某个机构的具体需求。审查者的领域知识提供不同参照，也能让讨论重新回到最初建立的共同理解。

在演示中，另一个代理审查计划并质疑其中的假设。用户可以把有用建议合并回主计划，也可以将其驳回。讲者认为，如果第二个模型的反馈无法改变实际财务决策，那么仅让它充当裁判的价值有限。

五项原则分别是共同理解、一致性、证据、责任与验证。讲者建议将它们结合起来，用于用户既需要相信分析结果、也需要相信背后过程的财务系统。

一位听众问，团队应该建立多少专门系统，以及它们应该有多具体。Caso 说，这没有固定周期或统一答案：应考虑通用方法出错的频率、可重复性的重要程度、用户数量和决策的关键程度。

低风险任务可以让人多花几轮对话，审查并引导现有代理。而支持 50 名信贷分析师决策的工具，对一致性的要求不同。团队应把这种需求与构建和维护新系统的成本一起权衡。

Galletta 指出，并非每项创意任务都需要同等程度的证据和审查。工作坊的方法源于财务工作的较高风险，并不意味着所有代理都需要完全相同的控制。

Galletta 把过度打造工具比作一直磨斧头却不使用。可以先按需添加指令或工具；如果复制内容、重启聊天和纠正结果这些别扭步骤反复出现，才可能值得为其设计专门工作流。

有人问专门代理是否帮助他筹备婚礼。Galletta 说，网络研究有助于比较摄影师和场地，但财务规划的容错空间更小。他回忆，自己开车时曾把基本相同的预算对话重复三遍，因为总有地方出错。

一位参与者问，如何应对领导对 AI 辅助分析必须完全准确的期待。Caso 回到结果本身：先约定成功的衡量方式，例如减少核对仪表板时的来回沟通，或减少关于可疑数字的工单，再衡量工具是否有帮助。

谈到代理 skill 与独立工具的边界时，Caso 说，指令可能运行得很好，但仍会遇到边缘情况或用户级指令冲突。当工作流覆盖更多用户、后果更加重要时，确定性的后端代码可以强制执行提示词只能请求代理遵循的行为。

Caso 举例说，共享代理扩展可能不断增加指令，试图处理用户提出的各种不受支持的请求。随着分发范围扩大，这些指令可能与其他上下文冲突；后端边界可以让支持的行为更可预测。

财务工作把可靠计算与解释判断结合在一起。比如，一笔收入可能记在不同月份，理解其影响需要判断；计算本身仍需可靠运行。Galletta 认为，系统设计应有意识地兼顾这两类工作。

模型也许会继续进步，但讲者认为，信任仍需通过外围流程建立。有些用户需要查看代码，有些更看重可追踪的证据或独立质疑。演示结合多种机制，因为没有一种界面展示能让所有人放心。