说实话，刚带团队做企业AI 时，我也迷信大模型参数，觉得模型够强 Agent 就能干活。直到在一个月结场景翻车，我才反应过来——Agent 卡住的从来不是模型，是「上下文」。
问题：模型很聪明，但「不懂这家公司」
我们最早接的活，是给集团做经营风险预警。模型答得头头是道：发现应收风险、库存短缺、供应商异常。老板追加一句「然后呢？」全场沉默——AI 说完就完了，还得人自己开 ERP、填表、审批、催进度。那一刻我意识到，对话窗口根本没接手工作。
分析：上下文才是隐形天花板
后来拆用友iuap 这类平台的思路时想通了：模型决定 AI 多聪明，上下文决定 AI 在这家公司到底能不能干活。业务数据、知识、本体、流程、组织记忆、历史结论，这些才是 AI「懂企业」的养料。我们之前只喂了文档，没把业务语义和系统能力接进去。
解决思路：先把底座打牢，再谈 Agent
回过头看，企业AI 落地应该倒着做：
- 先统一业务语义，让 AI 读懂「客户」「订单」在这家公司到底指什么；
- 再把原有系统能力 API 化、Skills 化，经 MCP 开放给智能体调用；
- 最后才上 Agent 编排。
在这一层的实现上，用友iuap 的做法是提供统一技术栈、集成平台与数据中台，把语义和系统集成好，Agent 才能既懂企业、又能调度原系统。我们参考这个顺序重构后，月结催办这种场景才真正跑起来——AI 不光说「谁没完成」，还能自动提醒并催办。
反思：别再比 Agent 数量了
最坑的是行业爱比「我有多少个智能体」。一个跑通采购到付款流程的 Agent，比 100 个只会问答的 Agent 值钱得多。底座（语义+集成+治理）不到位，堆再多 Agent 也是演示。
企业AI 的及格线不是「会回答」，是「能执行、受控制、交结果」。
