一个采购经办人正在填 OA 采购单。
页面上有金额、预算科目、部门、项目编号、供应商、附件清单。
他真正想知道的，不是“公司有没有采购 Agent”。
他只想在提交前知道三件事：预算够不够，材料缺不缺，制度有没有冲突。
如果这时候你让他打开另一个聊天框，再把采购单内容复制过去，Agent 就已经输了一半。
它增加了一个新入口，却没有接住原来的工作。
企业做 Agent，第一问不是它叫什么，而是它到底出现在什么页面、读取什么数据、把结果交还给谁。
这也是这节课件里最重要的一句话：Agent 建在哪里，要跟着用户工作现场走。
一、先别问 Agent 叫什么，先问它出现在哪个页面
离开业务页面的 Agent，很容易变成另一个待处理入口。
采购预算预审这个场景里，最自然的入口不是独立 App。
而是 OA 采购申请页的侧边栏。
用户填单时，系统已经知道采购金额、预算科目、部门、项目编号和附件状态。
这时 Agent 不需要重新问一遍“请描述你的需求”。
它应该直接读取当前页面的业务上下文，给出预审结论。
如果第一版集成成本高，也可以先做旁路网页或 IM 助手。
但旁路不能变成永久形态。
它的目标是验证价值，再回到真正的工作页面。
二、入口不在现场，AI 就会变成“多一步”
一个工具只要让业务多复制一次、多解释一次、多切换一次，就会被真实工作流抵抗。
这不是员工不愿意用 AI。
而是他们没有理由为了一个建议，额外承担整理上下文的成本。
采购经办人在 OA 页面里已经完成了大部分事实录入。
主管复核时，也是在同一个单据上看金额、依据、风险和附件。
所以 Agent 的位置要跟着这两个动作走。
经办人提交前，它给补件清单和风险建议。
主管复核时，它给依据、制度条款和待确认项。
同一个 Agent，可以服务两个角色。
但它必须嵌在同一条业务链路里。
三、Agent 服务层不是模型壳，而是执行层
只把大模型包一层接口，不叫 Agent 服务层。
真正的服务层，至少要管四件事：提示词、Workflow、Skill、权限。
提示词负责让模型理解任务。
Workflow 负责让任务按步骤推进。
Skill 负责把预算检查、材料检查、制度匹配、说明生成拆成可复用能力。
权限负责决定它能读什么、能写什么、什么时候必须停下来找人确认。
这里的重点不是技术名词。
重点是把“一个聪明回答”变成“一个可控制的业务过程”。
Anthropic 在智能体实践文章里，也把预设路径的 workflow 和更开放的 agent 区分开来。
采购预算预审这种高规则、高责任场景，更适合先从 workflow 起步。
不要一上来就追求完全自治。
四、它读什么数据，决定它能不能给出可验收结论
没有业务事实的 Agent，不是数字员工，只是临时顾问。
采购预算预审至少要读七类数据。
采购金额决定是否触发预算检查。
预算科目决定查哪一个预算池。
部门和项目编号决定责任主体。
供应商状态决定是否存在资质风险。
附件清单决定材料是否齐全。
制度条款决定审批要求。
这些数据不是用来“丰富回答”的。
它们是可验收结论的证据。
所以输出里不能只写“建议补充材料”。
它要说清：缺哪份材料，依据是什么，影响哪个审批动作，谁需要确认。
五、最重要的设计不是自动批准，而是结果回写
高风险流程里，自动化的第一步不是替人批准。
而是把结果稳定写回业务系统。
采购经办人需要看到补件清单。
主管需要看到预审依据。
财务或流程负责人需要看到人工确认项。
这些结果如果只留在聊天窗口里，就很难进入后续流程。
真正有价值的输出，应该回到 OA 单据里。
它可以是一段预审说明。
也可以是风险标签、补件清单、制度条款引用、人工确认项。
但它不能悄悄替人完成批准。
它也不能自动占用预算。
它更不能替财务做最终结论。
边界设计不是保守。
边界设计是让 AI 能进入生产环境。
六、第一版最好做成旁路验证，而不是直接改核心系统
第一版 Agent 不要急着改 OA 主流程。
更稳的做法，是先做一个旁路预审。
经办人在提交前点击预审。
系统读取单据字段和附件清单，调用预算系统、制度库、供应商库。
然后生成预审说明、补件清单和人工确认项。
主管复核时，可以看到同一份依据。
这一步的目标不是证明它能自动审批。
而是证明它能稳定辅助一个节点。
稳定辅助，比炫耀全自动更重要。
因为企业真正担心的不是 AI 不够聪明。
他们担心的是责任说不清、依据找不到、异常停不住。
七、明天就能开始：用五个问题画出第一版架构
很多团队做 Agent 时，一上来就讨论模型、平台和多 Agent 编排。
但真正能推进业务共识的，是五个很朴素的问题。
放在哪里。
谁触发。
读什么。
输出给谁。
不能做什么。
这五个问题答清楚，方案就不再虚。
老板能看出价值边界。
业务能看出使用场景。
IT 能看出接口和权限。
流程负责人能看出风险控制。
八、真正改变的是流程团队的位置
Agent 落地以后，流程团队不能只做制度发布者。
他们要变成能力设计者。
过去，流程文件写的是“应该怎么做”。
现在，还要把这句话翻译成系统能执行的接口、规则、Skill 和验收样本。
这不是让流程团队去写代码。
而是让他们把业务经验讲成可运行的结构。
哪个节点适合自动检查。
哪个节点必须人工确认。
哪个异常应该暂停。
哪个输出能回写系统。
这些判断，本来就属于流程和业务专家。
AI 只是把这些判断推到了更细的颗粒度。
九、不要从“全自动”开始，从“可确认”开始
企业 AI 的第一步，不是把人从流程里拿掉。
而是让人在更少噪声里做更清楚的确认。
采购预算预审就是一个很好的起点。
它有明确入口，有现成字段，有外部系统，有制度依据，也有清楚的责任边界。
你可以先让 Agent 做三件事。
第一，提前发现预算、材料、制度冲突。
第二，把依据和证据写进同一张单据。
第三，把高风险动作交还给有权限的人确认。
这已经足够产生价值。
它减少返工，减少主管追问，也减少审批流里来回补材料的时间。
更重要的是，它让组织学会一种新能力：把流程节点设计成 AI 可参与、可记录、可审计、可迭代的业务能力。
等一个节点跑稳，再复制到预算调整、项目立项、费用报销、合同评审。
这条路不刺激，但它更像企业真正能走通的路。
未来企业之间的差距，不会只来自谁买了更强的模型。
差距会来自谁更早把工作现场、业务系统、权限边界和人工确认串成闭环。
Agent 最后建在哪里，其实是在回答一个管理问题：你愿不愿意把组织经验，变成系统能执行的能力。
参考阅读： Anthropic：Building effective agents、 OpenAI Agents SDK：Agents、 OpenAI Agents SDK：Guardrails。