做企业 AI 平台最容易陷入的误区，是把“接入老系统”当成核心能力来吹。

做到这个阶段才看清：接管老系统是下策。上策一直是让企业自己改造系统、开放 MCP 接口。 把这件事的优先级排清楚，比再多堆一个功能都重要。

这一周的工作，大致围绕几条主线展开：团队精简之后的架构收口、三条并行功能线的推进、一次客户来访带出来的“企业中枢”画像，以及一个悄悄发生的趋势——所有应用都在准备一套面向 Agent 的接口层。

一、人少之后，反而开始做减法

团队从一群人收缩到两个人之后，第一件事不是继续往前赶，而是回头把自己写的东西扔进成熟框架。

起因是一个反直觉的现象：同一套提示词，在一个模型上能按结构输出，换到另一个模型上就完全失控。查文档才发现，LangChain 已经把三大模型厂商的输入输出标准都做了适配，工具管理、流程编排也都覆盖了。自己再写一层，只是重复造轮子，还更不稳定。

这次重构的范围不小——把过去自己实现的模型交互层，逐步迁移到 LangChain 的能力之上。

人少之后，反而敢做减法。这是收缩带来的清醒，不是退缩。

二、三条并行线：认证、服务集成、价值证明

并行推进的三件事：

• 多渠道认证：钉钉认证接入，授权链路打通

• 服务集成：MiroFish 平台化整合

• 效率看板：Token 消耗、节省时间统计

前两条上一期已经写过。这一期值得单独说的是效率看板。

企业级 AI 平台过去一直缺一件东西：价值证明。员工用没用、用得多深、为公司省了多少时间、烧了多少 Token，老板看不到，预算就推不动，这套系统就永远是“试用品”。

效率看板的意义不在于技术，在于让 AI 平台从“成本中心”变成“可计量的生产力”。

三、上策与下策：一个迟来的诚实排序

接管老系统的接口探索能力，过去几期一直在打磨。但真正交付到客户面前的时候，要先把优先级讲清楚：

• 上策：基于原系统做 MCP 改造。接口、权限、稳定性全部握在企业自己手里，这是确定性的工程。如果企业有开发能力，这条路最稳。

• 中策：把内部接口文档喂进知识库，让 AI 读完之后形成 Skill。半自动，适合有文档没团队的场景。

• 下策：接口爬取。只有当老系统没有维护团队、没有二开能力、文档丢失的时候，才用这条路兜底。

下策不是不做。它是兜底，但不能当主力卖。

这个排序之所以重要，是因为客户的直觉刚好相反——他们最容易被“自动爬取接口”震撼到，觉得这才是 AI 的魔法。但魔法越炫，稳定性越差。把上策放回第一位，是对企业的负责，也是对自己交付质量的负责。

四、“企业中枢”这个画像，是从客户嘴里讲出来的

这周有一次外部来访，讲了一组数字——原来 20 个行政岗，现在 3 个就够。但真正被节省的不是人员工资，是 20 多套外部专业系统的维护成本。

一个稍有规模的企业，通常会有几十套软件：人事、财务、审批、薪酬、停车、门禁、招聘、报表……每一套都要有人懂、有人登、有人导。高管不会用系统，需要数据全靠下属去翻。董事长想看一张报表，链路要走过三个人。

把所有系统的接口接到一个 AI 中枢上，聊天就能调数据——表面是行政效率提高，背后是企业把“数据孤岛的维护负债”一次性压缩。

这个画像和之前几期讲的“知识库 + 工作流 + 接管”完全对得上。区别只是视角——从内部看是“功能完整”，从客户看是“维护负担转移”。

后者才是企业愿意付钱的理由。

五、一个安静的迁移：图形界面正在让位给 Agent 接口

还有一件容易被忽略的事：目前所有应用的图形界面，都是为人服务的。按钮、表单、弹窗、列表，这一整套交互范式，假设的是一个人在屏幕前点击。

但是接下来真正使用这些应用的，会是 Agent。Agent 不需要按钮，需要的是 CLI 风格的接口、结构化的输入输出、可以被自动调用的能力。

这件事正在悄悄发生。飞书、钉钉、各种平台，都在补一套面向 Agent 的接口层。当主流应用都完成这次迁移的那一天，企业 AI 平台才真正能跑起来——不是依赖“爬取”和“模拟点击”那种脆弱方式，而是有一套原生为 Agent 设计的世界。

下策会逐渐消失，上策会变成标配。

几个月之后回头看，一个项目做到这个阶段，标志不是功能多了多少，而是开始敢把哪些东西排到“下策”里去。

这，是第三十三天。

《从0到1：企业级AI项目迭代日记》记录一个企业级 AI 项目从创意、架构到落地的真实过程。不讲神话，只记录进化。

---

如果你也在做企业 AI 落地，欢迎留言来聊。或者，把这篇转发给一个正在踩同样坑的朋友。