为什么人工智能原生平台会赢——它到底指什么

「面向销售／项目／支持的人工智能」这类发布，大多演示做对了，工作流做错了。提示词框得漂亮，回答流式吐出得顺滑，视频也拍得动人——可一进生产环境，智能体就忘了客户上一次沟通说了什么，看不见正在进行的项目，也不知道那张没付的发票。

原因不在模型质量。前沿模型非常出色。原因是结构性的：一个通过 API 读取 CRM 的智能体，上下文是稀薄的。

「上下文稀薄」到底指什么

当人工智能助手被挂在 CRM 上，它看到的就是 CRM。挂在项目工具上，它看到的就是项目工具。每一个集成都是一次单独的读取，各有各的鉴权、各自的限流、各自的数据形态、各自的延迟预算。

要向助手问一个真实的问题——「本季度哪些客户存在风险，为什么？」——它必须：

1. 读取每个客户及其所处阶段。
2. 与未关闭的支持工单交叉比对，找出不满意的客户。
3. 与进行中的项目交叉比对，找出交付风险。
4. 与发票交叉比对，找出回款问题。
5. 综合出答案。

在一套五个工具的技术栈里，这意味着五个集成、五轮鉴权来回、五个争抢 token 的上下文窗口。其中有些集成根本不存在。有些是只读的。有些把数据锁在更高的价格档位后面。有些返回的是摘要，而不是记录。

于是助手要么放弃，只凭 CRM 作答（错的），要么用残缺的数据编出一份综合结论（更糟）。

「单一图谱」带来什么

Cyril 的构建方式是：每一个实体——客户、联系人、商机、项目、任务、工单、文档、发票、费用——都活在同一张图谱上，共用一套权限模型，共用一种数据形态。每个实体都提供一个 ai_context 序列化器：一份确定性的、理解自身模式的记录视图，专为给人工智能提供事实依据而构建。

同一个智能体，在 Cyril 上回答同一个问题：

1. 读取每一条客户记录（一次查询，按 org_id 限定范围）。
2. ai_context 里已经包含关联的工单数量、项目状态、发票状态。
3. 综合出答案。

一次查询，没有集成胶水，没有缺失的数据。模型去做模型擅长的事——综合——而不是跟架构搏斗。

为什么这是一个工程决策，而不是市场决策

单一图谱无法事后改造到一个并非为它而建的平台上。每一个 API 的形态、JWT 契约、迁移体系、测试范式——所有这些都必须从第一天起，就把人工智能智能体当作与人类平级的调用方来设计。

这正是「人工智能原生」是一项结构性主张、而非功能主张的原因。它要么贯穿地基，要么就是挂在上面。

Cyril 贯穿地基。packages/mcp 里的 MCP 服务器负责把平台工具开放给外部智能体。ai_context 序列化器在每个实体上都是强制的。模型抽象层是强制的，不锁定任何供应商。智能体的每一个动作都可审计、可撤销。

这对你意味着什么

• 问一句「Phoenix 项目过去七天有什么变化？」，一次就能拿到横跨销售、项目、工单与文档的答案。
• 运行跨模块读取的自动化——商机赢单触发项目创建、启动会排期、欢迎邮件入队——不必忍受集成延迟或字段缺失。
• 让智能体跨模块执行动作，只需一套权限模型、一份审计日志、一条回滚路径。

这就是「人工智能挂在五个工具上」与「人工智能生在一个系统里」的区别。两者都能做出漂亮的演示。只有一个能熬过第一个真实的工作流。

常见问题

这是在讨论人工智能，还是在讨论数据模型？

在讨论数据模型。人工智能这一层只是让后果显形；而真正被主张的东西——一套模式、一套权限模型、一份审计日志——即便没有模型存在，也同样值得拥有。人工智能只是抬高了不拥有它的代价。

一个足够好的集成层能不能就够了？

它能搬运记录，这确实缓解了一部分痛苦。但它无法造出一个可供提问的共享模型，而那恰恰是智能体需要的部分。五个维护良好的集成，留下的仍然是五套词汇，以及对 status 究竟意味着什么的五种理解。

这需要更大的模型吗？

不需要，而这正是重点。前沿模型早已擅长综合。上下文稀薄不是靠更强的能力解决的——一个更好的模型只拿到五分之一的数据，回答的仍然只是五分之一的问题，只是说得更流畅。

从外部分辨两者，最快的办法是什么？

要求对方回答一个跨两个模块的问题，然后留意「集成」这个词，或者留意答案是否悄悄收窄到单一孤岛。这种收窄就是信号。

---

如果你希望成为最早使用 Cyril 的用户，加入等候名单。