第四课　真正难的不是执行，而是把公司的隐性流程画出来

文档里的流程，与公司真正运行的流程

Moza认为，执行正迅速变便宜，下一道瓶颈是理解业务。这个判断带有演讲者鲜明的乐观立场——他甚至说知识工作的执行“近乎被解决”——但他指出的现场难题非常具体。

过去两年，模型从回答问题走向执行任务。API是软件之间按约定请求数据或动作的接口；MCP（Model Context Protocol）则是让AI应用以统一方式连接外部工具和数据源的开放协议。浏览器操作、API工具、MCP和各种Agent运行框架，让AI可以登录系统、读取数据、填写表单、发送消息。于是企业很容易产生一种错觉：只要模型足够聪明，再给它工具，流程就会自动运转。Moza的反驳是，执行能力增长并没有自动带来业务理解。模型能点按钮，却不知道这家公司为什么在这里停一下、为什么另一家公司在同一步骤必须多找一个人批准。

这种差异往往不在行业层面就能解决。同样是销售部门，医疗公司的客户资格、合规要求和采购周期，与SaaS公司的线索分配和续费动作完全不同；同样是应付账款，两家企业对发票容差、供应商例外和审批层级也可能完全不同。通用模型掌握了“AP通常怎样运作”，不等于掌握了“这家公司的AP今天怎样运作”。后者需要从人员、记录和异常中重新建模。

以财务部门为例。FDE会分别访问应付账款（AP）、应收账款（AR）、卡片对账、银行、账单和财务规划分析（FP&A）负责人。正式流程也许写着：收到发票、匹配采购单、审批、付款。但真实情况更像这样：正常单据由Sarah处理；采购单与发票对不上时，她转给Chris；Chris要等待另一个部门回复，四天后才能继续。

这些流程也不是彼此独立的六条线。AP发生的付款会影响现金预测，AR回款会改变FP&A的判断，银行卡对账又可能暴露费用系统里的异常。每个流程负责人都会合理地认为自己的问题最紧急，却只有跨流程观察才能看见真正的依赖。FDE若只采访一个部门，就可能优化局部步骤，同时把等待或风险推给下游。

公司的文档通常记录黄金路径（golden path），真正决定自动化成败的却是边缘情况：信息不全、角色重叠、审批人休假、两套系统的同一人拼写不同、某个部门临时绕过正式规则。Agent若只学到理想流程，异常一来就会停住或自信地做错。

所以FDE的第一项工作不是写Agent，而是建立一张足够真实的流程地图：谁在什么时候需要什么信息，依赖什么前置条件，错误交给谁，多久之后才算失败。

地图至少要同时容纳四种事实。其一是正式规则，例如采购金额超过多少必须升级审批；其二是系统状态，例如发票是否已经入账；其三是组织关系，例如某位负责人休假时谁能替代；其四是经验判断，例如哪些供应商虽然字段不全却通常可以放行。前三类较容易进入数据库，第四类往往只存在于老员工的习惯里，却恰恰决定Agent能否处理真实世界。

不要把AI贴在一条坏流程上

理解现状之后，第二步不是原样自动化，而是重新设计。Moza给出一种三分法：

1. 完全自主：风险可控、规则清楚、结果容易验证的步骤交给Agent；
2. 人在回路（human in the loop）：Agent准备材料或建议，人类批准关键动作；
3. 纯人工：高风险、价值判断密集或极少发生的步骤继续由人处理。

假设原流程有八步，可能四步由Agent自动执行，三步需要人工确认，一步保持人工。目标不是把十一键点击粗暴压成一个按钮。业务人员需要理解系统怎样运作，组织也需要逐步建立信任。变化太小没有投资回报，变化太大则可能因采用失败而一无所获。

这里有一个容易被技术团队忽略的采用悖论。假如员工十年来一直按十一段完成工作，突然出现一个按钮声称可以全部代劳，即便它真的有效，人们也未必立刻信任。因为旧流程除了完成任务，还让员工看见控制点：他们知道什么时候能检查、什么时候能撤回、出了错该找谁。把步骤减少到一个按钮，同时也可能把可理解性一起删除。

因此，流程重构既不能只追求“与过去相似”，也不能只追求“自动化比例最高”。合理做法是先保留关键检查点，让Agent承担准备、匹配和重复执行，人类在高风险动作上确认；等评测和运行记录积累起来，再逐步扩大自主范围。组织信任不是培训会上宣布出来的，而是通过连续、可解释的正确执行建立的。

把旧流程重画成人机分工

五年、五百万美元的系统不会因为AI被扔掉

一家客户告诉Varick，他们花了五年和五百万美元迁移到NetSuite。现在若有AI供应商说“我们的方案很好，但你得先迁出NetSuite”，答案几乎一定是否定。

企业把ERP、CRM和财务系统称为记录系统（systems of record），因为关键数据、权限和审计责任都在里面。ERP管财务、采购、库存等企业资源，CRM管客户、销售与服务关系。Agent若完全绕开它们，只能成为另一个信息孤岛。Varick的选择是在 Salesforce（CRM平台）、NetSuite（云ERP）、Microsoft Dynamics（CRM与ERP应用套件）或 SAP 之上构建Agent，通过既有系统执行动作，而不是要求客户再次推倒重来。

“记录系统”这个词的重点不只是数据存放位置，而是制度上的权威。月底结账时，财务人员相信哪一套余额？审计追问一笔付款时，哪一套日志具有证据效力？员工离职后，权限从哪里收回？AI可以在邮件和文档里形成很好的建议，但若最终动作没有写回ERP，企业仍要由人手工同步，新的自动化层很快会制造另一套不一致记录。

在旧系统之上建设，也不是简单调用几个API。Agent要继承原有权限，区分读取、建议和执行；写入前要检查前置状态，写入后要留下审计记录；发生错误时要能暂停、回滚或交给人。对财务场景而言，一次重复付款或错误入账的代价，远高于模型回答得不够漂亮。FDE必须把模型行为放回企业控制体系，而不是让企业适应一套脱离现实的新控制体系。

这条现实约束也划清了演示与部署的差别。演示可以上传一份文档并输出答案；生产系统必须知道谁有权读写、动作怎样回滚、记录留在哪里、失败时由谁接管。

为FDE本人造一个Agent

Varick的FDE遇到了一个讽刺场面：平台工程团队用着各种编码Agent，隔壁负责客户的同事却被邮件、会议记录和上百页文档淹没。他们把材料上传给通用模型，等待很久，得到的分析又冗长又常抓错重点。

JD回忆，他所在的平台团队用Codex、Claude等工具写代码，工作节奏相对轻松；抬头看另一边，FDE却长期缺觉。客户全天发邮件，不同流程负责人把团队拉向不同方向，一次分析可能先要上传约150页材料，再等通用模型输出一段冗长且重点错误的回答。问题并不是FDE不会使用AI，而是通用助手没有一套适合持续客户参与的记忆结构。

这也暴露了FDE扩张最现实的瓶颈。理想人选既要是能够理解模型、系统和数据的顶尖工程师，又要有足够的沟通能力，在客户不完整甚至互相矛盾的叙述中提取事实。企业常见的两条培养路线——把咨询顾问训练得更技术，或把工程师训练得更善于沟通——都需要时间。Varick因此不指望无限招聘“高IQ加高EQ”的稀缺人才，而是尝试用Agent扩大每个人能管理的上下文。

JD据此设计了三阶段FDE Agent：

第一阶段：参与助手（engagement agent）。 它读会议笔记、文档、幻灯片和消息，回答“这个流程由谁负责”“两种拼写是否是同一个人”等上下文问题。

这一阶段看似只是企业搜索，实际要求比一次性问答高。会议笔记里写“Sarah”，邮件签名可能写全名，Slack里又使用昵称；同一个缩写在财务和技术团队含义不同；流程负责人一个月后可能更换。参与助手需要把来源、实体和时间对应起来，让FDE能追问“是谁说的”“当前负责人是谁”，而不是从一堆材料中生成一段无法追溯的概括。

第二阶段：工作流助手（workflow agent）。 它嵌入Varick自己的平台，在FDE搭流程时提醒遗漏的边缘情况、责任人和依赖关系。

嵌入平台很关键。若助手只在聊天窗口里给建议，FDE还要自己把答案翻译成流程节点；当它与构建界面并排工作，就能检查当前设计是否漏掉例外、发送对象是否正确、一个审批是否在前置步骤完成之前被触发。上下文从“可读材料”变成“可执行约束”。

第三阶段：自主维护助手。 未来，客户发来“把质检报告改发到另一个地址”之类的小请求时，Agent能查询公司知识、修改流程并提交变更，让FDE把时间留给访谈、判断和重构工作。

第三阶段在演讲时仍是目标，而不是已经全面完成的能力。它真正困难的地方不在修改一个邮箱地址，而在判断请求是否来自有权修改的人、变化会影响哪些下游节点、是否需要测试和批准。若这些条件满足，Agent才能把零碎维护从FDE手里拿走；若条件不满足，它应生成变更建议而不是自行上线。

公司的运行方式需要一种机器可读表示

这套系统的底层不是一堆散文式文档，而是一张依赖图。一个审批必须发生在另一个审批之后，一个人可能在邮件与Slack里有不同名字，一个流程可能包含回路。图数据库还是普通关系数据库并非重点；重点是建立统一、可查询的公司表示。

JD认为，大多数企业流程的主干其实相当线性：A完成后才能到B，B批准后C才有资格行动。复杂性来自分支、重试和循环——信息不全退回补充，对账失败交给另一人，再回到原节点继续。依赖图适合表达“哪些事实必须先成立”，也便于检查某次修改是否让流程出现无法结束的环。

技术选型反而是次要的。团队可以使用专门保存节点和关系的图数据库，也可以在通用开源关系数据库PostgreSQL里表达这些关系；重要的是每个节点和边都有稳定含义，并能追溯到原始证据。没有这一层，所谓“公司知识库”只是更多文档，模型仍要在每次请求中重新猜测流程结构。

JD把技术问题分成两半：第一，从已有上下文中写出准确、克制的流程分析；第二，从巨大知识图中抽取真正相关的上下文。Varick选择在开源模型上做后训练，并在强化学习环境里教模型使用实体消歧、发现冗余循环和检查有向无环图违规等专用工具。后训练是在基础模型完成预训练后，再用特定任务数据和反馈调整其行为；强化学习则让模型根据行动获得的奖励信号学习策略。字幕对具体模型版本的识别不够可靠，本书不锁定名称；方法比型号更重要。

第一半并不只是“模型会不会总结”。JD观察到，前沿模型写长分析时往往非常详细，却缺乏咨询顾问式的取舍：不知道哪些细节会改变客户决定，哪些可以暂时略过。Varick用自己的流程样本后训练模型，目标不是让文字更华丽，而是让输出在完整与清晰之间找到适合交付的密度。

第二半更接近检索与推理。即使已经有一张巨大的知识图，模型也未必能稳定走到正确节点。团队为此提供专用工具，例如判断两个拼写不同的人名是否指向同一实体、寻找重复步骤、发现本应无环的依赖关系中出现了循环。再在强化学习环境里训练模型选择和使用这些工具。先找到正确上下文，再写出有用分析；两步缺一不可。

自动化FDE，还是放大FDE

Varick把项目称为“AI FDE”，但近期目标不是删除现场工程师。Agent先接管资料整理、重复核查和小型维护，让一名FDE同时维持更多客户上下文。最难的工作仍是：让业务人员说出没有写下来的例外，判断哪些流程值得改变，并在风险、回报与接受度之间做设计。

Varick自己的交付顺序也说明了这一点。一次参与先从审计开始，FDE和策略人员进入一个部门，理解它从内部怎样运行；随后才进入实施，在平台上构建Agent。技术平台不可缺少，但它出现在理解之后。如果顺序颠倒，团队很容易拿着现成Agent寻找使用场景，最终只在旧流程上增加一个新的聊天入口。

Moza主张按整个部门而不是单一点方案思考回报。只自动化获客或AP的一小段，收益可能被上下游等待抵消；跨流程重构才有机会同时改变收入、成本和风险。他在演讲中给出的25%、50%乃至75%回报属于公司项目口径，不能当作普遍保证，但它提醒我们，Agent价值常常取决于流程边界画在哪里。边界太窄，AI只能让一个局部动作更快；边界足够完整，才可能改变部门的运行方式。

换句话说，Agent最先自动化的是FDE的行政负担，而不是FDE的责任。

把流程画清楚之后，新的问题马上出现：可以自动化的东西仍然很多，团队先做哪一段？谁说的“紧急”才是真正的紧急？下一课进入Ramp的工程队列，讨论FDE最容易被忽视、也最能节省成本的一项能力——在写代码之前压缩范围。