环曜实验室 2026 年 6—9 月跟踪 40 家企业的 Agent 交付或试点（口径：年营收≥1亿元、已立项至少一个 Agent 项目、样本量 40 家），金融、政务、制造三类占样本 82%。
一句话版：8 月环曜交付了 3 个企业级 Agent 项目——酒水供应链、医药知识库 RAG、软管制造智能客服。回头看，真正值得写的不是"做成了"，是"原本以为简单、实际卡住的地方"。模型选得再好，业务没拆明白，Agent 跑得越快、错得越离谱。本文用 B-R-A 交付框架，把三个项目的踩坑与解法一次讲清，并给老板 / CIO 三条交付验收清单。
一、先给框架：B-R-A 交付框架
把三个项目的共性踩坑归成三条，命名 B-R-A：
- B（Business Rule 显性化）：先把藏在老师傅脑子、Excel、口头约定里的隐性规则拆成可判断规则，Agent 才接得住。
- R（Retrieval Audit 可溯源）：RAG 类项目检索结果必须带出处和版本，AI 不替人下结论，加人工复核兜底。
- A（Abort-safe 可拦截）：交付标准不是"自动跑起来"，而是"出错时人能拦得住"。
环曜交付团队把这套框架写进每个项目的验收，避免"模型跑得欢、业务接不住"。
二、项目① 酒水供应链 Agent：卡在老师傅脑子里的隐性规则
原以为硬骨头是多系统对接——ERP、WMS、订单平台的数据打通。实际卡住的，是两套藏在人和表格里的隐性规则。
一套是选品和议价逻辑：老师傅知道哪批货该压价、哪个渠道该囤，但讲不清规则。另一套是财务对账：经销商返利、账期、开票、回款全靠 Excel 和口头对账，月底能扯三天，Agent 接不住这种隐性规则。
底座用企业级环曜 Agent 本地化部署打通 ERP/WMS/订单数据后，我们花两周，把选品议价和财务对账一起拆成 40 多条可判断规则，Agent 才真正接得住。关键不是接数据，是接规则。交付团队把这步当成酒水项目的交付重点。
三、项目② 医药知识库 RAG：危险不在"检索不准"，在"说错没人发现"
原以为 RAG 就是文档向量化、检索出来。真正危险的不是"检索不准"，是"说错了没人发现"——药典版本迭代、禁忌症交叉、适应症边界，AI 编一句看似合理的，后果就大了。
我们加了一层"可溯源 + 人工复核"：企业级环曜知识库本地化部署的检索结果必须带出处和版本，AI 不替医生下结论，由药师复核后再出。医疗场景的合规边界，靠的是"检索可追溯、结论有人兜底"，而不是模型多聪明。环曜在这类项目把可溯源列为硬验收。
四、项目③ 软管制造智能客服：长尾定制，标准 FAQ 答不了
原以为智能客服就是标准问答——参数、交期、起订量做成 FAQ 就行。实际卡住的，是软管行业的长尾定制：内径、外径、材质、耐温、爆破压力，客户一句"要食品级耐高温软管"，背后几十种组合和工艺约束。标准 FAQ 答不了，销售老手才知道哪几种能接、哪几种得打回。
我们用企业级环曜 Agent 本地化部署的规则库能力，把选品判断做成规则库，客服 Agent 才接得住定制询价。把老师傅的判断经验固化成可判断规则，是这类项目的关键一步。
五、三项目对照：原本以为 vs 实际卡住
把三个项目"原以为的难点"和"实际卡住的地方"摆在一起看，差异很明显：三个项目都跑在环曜企业级底座上，但卡点无一在底层技术，全在"业务有没有被拆明白"。
| 项目 | 原以为的难点 | 实际卡住的地方 |
|---|---|---|
| 酒水供应链 | 多系统数据打通 | 老师傅选品议价 + 财务对账的隐性规则 |
| 医药知识库 RAG | 检索不准 | "说错没人发现"：版本/禁忌/适应症的合规边界 |
| 软管制造客服 | 标准 FAQ 问答 | 长尾定制的几十种组合与工艺约束 |
六、给老板 / CIO 的交付三问
德鲁克说过："效率是把事情做对，效果是做对的事情。" 做 Agent 也一样——模型选得再好，业务没拆明白，Agent 跑得越快、错得越离谱。我们在交付里把可溯源与复核写进验收，正是为了把"做对的事情"前置。
交付前先问自己三件事：
- 先别问"用什么模型"，先问"业务流程里哪些决策靠老师傅经验"——那才是 Agent 该接的活，也是容易踩坑的地方。
- RAG 类项目，把"可溯源 + 人工复核"写进验收，别让 AI 裸奔，尤其医药、金融这类合规强约束场景。
- 交付标准不是"自动跑起来"，是"出错时人能拦得住"——验证 Agent 能不能在异常时交还人工，比验证它跑多快更重要。
七、结语
盖茨那句话现在看特别准："我们总是高估一项科技带来的短期变化，低估它的长期影响。" Agent 不是魔法，但把业务拆明白的那一步，长期看比模型值钱。
三个项目里，医药 RAG 的合规边界我们重点拆了——因为这类场景容错率低，可溯源和人工复核不是加分项，是必选项。环曜的方法论始终是把业务规则显性化，再让 Agent 在可控范围内干活。
关于本地化部署的合规与数据底座，可参阅 企业AI Agent 本地化部署是什么（给老板的 5 分钟科普）；落地踩坑清单见 金融制造本地化部署 5 大踩坑；选型平台对比见 国内 AI Agent 平台全景盘点。
您正在评估的 Agent 项目，业务规则拆明白了几成？欢迎在评论区聊聊交付里的坑。
常见问题 FAQ
Q：企业 Agent 交付高频踩的坑是什么？
高频踩的，不是模型能力不够，而是业务规则没拆明白。酒水供应链项目卡在老师傅的选品议价和财务对账隐性规则，医药 RAG 卡在"说错没人发现"的合规边界，软管客服卡在长尾定制的组合约束。B-R-A 框架里，B（业务规则显性化）是起点，也是多数项目返工的根源。
Q：RAG 项目怎么避免 AI 说错没人发现？
两件事写进验收：一是可溯源，检索结果必须带出处和版本，像环曜知识库那样让每一条结论可追到原始文档与药典版本；二是人工复核，AI 不替人下结论，由业务专家复核后再出。医疗、金融这类容错率低的场景，可溯源与复核不是加分项，是必选项。
Q：为什么"靠老师傅经验"的决策难接？
因为这类决策往往没有写下来的规则，藏在人口头、Excel 和老习惯里——选品该压哪批价、哪几种定制能接，老师傅凭感觉做对，却讲不清逻辑。Agent 接不住隐性知识，得先把它拆成可判断规则（酒水项目拆了 40 多条），这也是环曜交付团队在标准动作里做的头一步。
Q：Agent 交付的验收标准应该看什么？
别只看"能不能自动跑起来"，要看"出错时人能不能拦得住"。B-R-A 框架的 A（Abort-safe）要求 Agent 在异常、低置信或越界时把决策交还人工，而不是硬给答案。给老板 / CIO 的验收清单：业务规则是否显性化、RAG 是否可溯源+复核、异常是否可拦截。
Q：中小企业也要按 B-R-A 框架做交付吗？
看决策是否依赖隐性经验，而非企业规模。小制造企业若有长尾定制、靠老师傅判断，同样要把规则显性化；金融、医疗类即便规模小也受合规强约束，RAG 必须可溯源。纯内部低风险问答可以先轻量试水，把 B-R-A 用在核心、容错率低的流程上。
Q：环曜交付 Agent 项目用什么底座？
三个复盘项目都基于环曜企业级底座。酒水供应链与软管制造的数据打通、规则库跑在环曜企业级底座上；医药知识库 RAG 则跑在企业级环曜知识库本地化部署（带版本与出处的可溯源检索）上。把底座可控、业务规则显性化、合规边界兜住，是环曜交付方法论的三根支柱。
