定制 AI agent 与业务流程自动化

这是什么

定制 AI agent 开发，加上业务流程的 AI 自动化：我们做的 agent，负责你工作流里那些重复的判断活——分类、抽取、对账、起草、路由——再围绕它搭一条流水线，让这些判断不必每一件都过人手。系统在能为决定负责的地方自动执行，拿不准的连同证据一起交回给人。

让这件事敢上生产的，是模型外面那圈工程，不是模型本身。我们交付的每条流水线都带置信度门控、用你的真实数据做过评测、全程留痕——因为一套自信地犯错的自动化，比没有自动化更糟。这套纪律才是产品本身；模型只是里面一个随时可换的零件。

我们反复在解的问题

想”把 AI 用进工作流”的团队，工作流大多早就有了。他们手上是一堆重复的判断活——给这张工单分类、从那份 PDF 里抽这几个字段、把两条记录对上账、起草这封回信——一个人一整天就耗在这上面。聊天机器人碰不到这些活。能碰的是这样一套系统：它自己做这些判断，知道自己什么时候没把握，并把没把握的那些连同证据一起退回给人。

难的不是让模型给出一个答案，而是让它对得足够多、可以放心交给它，并且一旦错就错得让人看得见。一套有 5% 的时候自信地答错的自动化，比没有自动化更糟，因为没人在复核。所以我们真正要回答的工程问题是：怎么让机器自己动手，又不让它悄悄犯下代价高昂的错。

我们怎么做

我们交付的每条流水线，骨架都是同样三块：置信度门控、评测兜底、全程审计留痕。

置信度门控。 流水线做的每个决策都带一个校准过的置信度。高于阈值就执行；低于阈值，这条就连同模型的推理过程和原始数据一起，上递到人工队列，让复核的人几秒钟就能拍板，而不用从头把这个 case 拼回来。阈值是按决策类型来的，不是一刀切——一笔退款审批和一个标签建议，不该用同一根标尺。是”低人工审查”，不是”无审查”。这套打法的完整工程细节——校准阈值、多来源一致、自动补缺而不是把所有不确定都堆给人工——写在置信度门控的自动化里。

评测兜底。 任何一类决策上线前，我们都用你的真实数据建一套带标注的评测集，在上面量它的精确率和召回率，跟测任何别的代码路径一样。这个数就是用来定置信度阈值的——把标尺往上抬，直到评测集上的精确率越过业务要的那条线，再只对越线的部分做自动化。这套评测集同时也是回归测试：模型或 prompt 一改，它就重跑，掉了就拦住这次改动。流水线要驱动真实 UI 的端到端检查，我们用 Playwright 来跑。

审计留痕，贯穿全程。 每一个自动动作都记下它的输入、模型输出、置信度、当时对照的阈值，以及它到底是执行了还是上递了。六周后有人问系统当初为什么这么做，能有个答案，而不是一脸茫然。这也是让那套归属权校验能真正落地的前提：自动执行者跟人一样，照样走同一套服务端授权校验，而留痕能证明它确实走了。

底层技术栈是有意做得很朴素的：agent 用 Python 和 TypeScript 来写，LLM API 藏在一层薄适配器后面，换模型只是改个配置；各阶段之间隔一道消息队列，某一步慢了或挂了不至于把整条流水线拖垮；整套部署在你已经在用的基础设施上。我们是接进你现有的系统，而不是另起一个还得你盯着的独立工具。另外，如果一个决策要以你自己的文档为证据——制度、合同、知识库——大多数问题会出在检索层，而不是模型；这一半我们怎么做，写在生产环境里的 RAG。

你能得到什么

需要人工复核的队列，会收缩到那些真正得让人看一眼的 case。这类任务的吞吐量，不再被人头数卡住。而且因为每个动作都连同它的置信度和证据被记下来，你能向审计、向客户、或者向你自己，证明系统当初做了什么决定、为什么这么决定。

要看一个最接近”标准参考”的实做，可以看我们的房贷文档抽取案例：一条 OCR + LLM 流水线，只在两个独立来源以高置信度一致时才自动填字段，扛不住的就自动回到客户那边确认——全程零人工录入，没有任何靠猜的值进入信贷档案。

要判断现在做这件事值不值：越来越多的 B2B 采购正在经由 AI agent 完成。落到运营层面是同一个转变——过去每一件都得有人盯着的活，会越来越多地不再需要，前提是系统对自己的不确定足够诚实。这份诚实，就是这件事的全部。