金融 Agent 的验收标准要写进设计文档
一、演示之后，第一个问题是「谁来证明」
九月上旬蚂蚁发布了一个金融增强模型，同时开源的还有一份评测基准，名字叫 FinFIRST。它测的不是问答的准确率，而是金融搜索里的信源选择、口径判断与推导过程。中文题占六成，超过五分之四的题目包含多个相关子问题，七成半不直接指定信源，要 Agent 自己去找、自己判断该信哪个。
这几行数字说明的事，比模型本身更值得记：他们把金融研究里的专业判断，翻译成了可以验证、可以复用的题目。一个行当能不能被工程化，先看它的判断标准能不能写成题。
二、后台才是重点
同一批报道里还有两句话讲得更直白。一句是前台界面只是入口，真正的变化发生在客户看不见的风控、审批、技能栈与实时数据库上。另一句是人机责任划分要写进设计文档：Agent 负责执行、探索、分析、试算，人负责定目标、定标准、判结果、担责任。
前一句与投研的处境严丝合缝。一个 Agent 能不能把一份信用分析做完，不取决于它会不会聊天，取决于后台有没有把财务、估值、舆情这些底库结构化到可以逐列取用的程度。后一句才是新的，它把责任由谁承担从会上的共识，变成文档里的一行。
三、我们原来的验收是打开页面看一遍
把一个模型接进流程之后，第一件让人停下来的事，不是它能不能做，而是怎么证明它做对了。最早的办法是人工打开页面看。看的人很认真，但每换一版就要重看一遍，代价随版本数往上走，而且总留下几样看一眼就会漏的东西。
后来把验收拆成三层。几何层算文字框有没有重叠、有没有越出画布；数据层核对页面上的数字与产物是否同源同序；渲染层把图真的画出来看。三层里最不直观的是第三层，也正是前两层替代不了的：几何层证明的是我算的文字框不重叠，证明不了渲染器画出来会是什么样。
渲染层的做法不复杂。同一张图渲染两次，一次原样，一次删掉所有文字节点，两张图相减，剩下的像素就是文字墨迹。没有阈值猜测，也不受字体、字重与配色的影响。同一列的墨迹如果连成一团，就是粘连；某一行的墨迹落不进任何一条带，就是它根本没画出来。
四、一次事故之后，检查项多了一条
头图上出过一次事故，副标题压在了标题上。事后再看，当时十七项检查全部通过，因为检查项里没有这一件事。真正的原因是版式里的纵向坐标是手工填的数字，改了上面一行的字号，下面几行的位置不会跟着动。
修法不是把数字一个个调对，是把坐标改成推导出来的：每一块的位置由上一块的视觉底边加一个间距得到，间距成了唯一的旋钮。手填坐标这件事本身被取消，同类事故就不再可能发生。
这条经验后来被写成规则：每修一类事故，第一件事就是把它变成一条检查项。检查项不会自己长出来，它是被事故换来的。
五、能现算的数字不要写死
同一个头图上有四个统计数字。其中一个曾经在代码里写死，写着二十一个公开仓库，而当时实际只有十六个。这类错误不报错，只是安静地挂在首页上，谁看都以为是对的。现在这四个数字全部由构建脚本从产物现算，展示顺序写在配置里，顺序本身也被检查：哪一项排第一、哪一项要排在另一项前面，都有一条断言守着。
写死的数字与手填的坐标是同一种错误，都是把一个本该推导的量当成了常量。区别只在于一个错在页面上，一个错在图里。
六、责任那一行要能让机器问到
第三条最难，也最该抄。我们的做法是把要人拍板的事情从对话里搬到一张网页上：Agent 想发布任何东西，先去登记一张卡，写清影响面与不可逆的程度，然后等。执行脚本的第一行查这张卡，拿不到放行就中止。
这里有一个必须显式写进设计的细节：闸门连不上时按未批准处理。最省事的写法是连不上就当作通过，那等于把闸门取消掉，还留了一行看起来在检查的代码。
还有一条同样要写进设计文档：对话窗口里的继续、可以、批准，全都不算批准。我常用的这套流程里，对话中断之后环境会自动补一句继续进来。如果把这句读成批准，前面所有的登记与校验都会绕过去。判断放行的唯一依据，是那张网页上留下的记录。
七、落点在文档里
回到开头那个问题。金融 Agent 从演示走到生产，卡住的从来不是能力，是怎么证明它行这件事没有被写下来。
写下来的样子是三条：验收标准与功能需求放在同一层，不推到测试环节去；能由产物现算的数字一律现算，展示顺序也由配置约束；凡是要人担责的动作，在脚本第一行有一个地方去问，答不上来等于不通过。
人做的事没有减少，只是往前挪了。目标是人的，标准是人的，结果是人判的，责任也是人的。Agent 拿走的是执行、探索、试算这些，以及过去被浪费在重复核对上的那部分时间。
本文为个人研究笔记，不构成任何投资建议。