CATLAXY · 实践笔记 #1 / PRACTICE NOTES

业务原生 Native AI 不是更好的 AI 工具，而应该是另一种产品形态。

一年来的平台开发设计实践：一个平台、多个 Agent、共享上下文。

DeepSeek 想问题，Kimi 分析长文档，秘塔搜索查资料，豆包整理素材；要画图找豆包或Nano banana, GPT-image2，要做短视频用可灵或即梦，要写代码用通义灵码或豆包 MarsCode；飞书做会议纪要，WPS AI 写文档（甚至一个团队共用一个帐号，由一个人统一作文档翻译）。一周下来，10 来个 AI 工具是常态。技术团队还会再加 ChatGPT、Claude、Gemini，做开发的同学甚至用上 Cursor、Claude Code、Antigravity 这类 agentic IDE。

每用一个工具，都要重新交代一次背景：业务是什么、客户是谁、上次聊到哪、要遵循什么规则。每跑出一个结果，要搬到下一个工具继续。每个工具单独看都聪明，叠在一起反而比没用 AI 之前更累，大脑要在不同 AI 的"短期记忆"之间反复回填上下文。

我一直在做的，不是一个更好的 AI 工具，而是另一件事：把多种 AI 能力放到同一个体系里，让它们共享上下文、互相调用、协同产出。业内有人把这个叫"业务原生 AI"。我用这个词指代我做的这件事，一个平台、多个 Agent、共享上下文。

一直以来，我们主要还是以业务谘询为起点帮助客户落地AI，但今天，我想从产品的层面，也跟各位分享一下我们一路走过来的思路，可以把它拆成五块拼图：

大部分企业用 AI 的第一道坎是：通用大模型不知道你的业务。

产品规格、合同条款、客户偏好、内部 SOP、行业 know-how，这些不在 DeepSeek、Kimi、通义、豆包们的训练数据里。每次跟 AI 对话都得在 prompt 里重新交代，交代不全 AI 就开始凭印象编。

业内常见做法是给每个 Agent 单独配一个知识库，文档塞进去，做成"这个 Agent 专用"的语料。这种做法在单 Agent 场景能跑，但只要业务超过一个 Agent 就开始崩：

我的判断是：业务知识应该是平台级共享设施，不是每个 Agent 自己的资产。

KnowledgeOS 是平台的知识中枢：

完整介绍 → 下载KnowledgeOS白皮书

我们一个跨境品牌客户的实际部署里，多个能力中心（营销、品牌、调研、销售、内容）共用同一份 KnowledgeOS。改一句产品定位，所有 Agent 立刻同步更新。更重要的是，营销 Agent 和销售 Agent 看到的客户画像是同一份，跨 Agent 协作不再因为"事实不一致"出错。

跟 AI 协作有两个常被忽视的地方：

业内常见的对话型 AI，问和给都是自由文字往返。AI 用一段话问"你想要什么样的报告？给谁看？大概多长？"，你用一段话回答。AI 解析回答可能解错，"产品和市场"被理解成"产品和市场分析师"，给你写了人物画像，出错就要回头重新沟通。

我的判断是：跟 AI 真正高效协作的关键在结构化进、结构化出。Catlaxy AI 在这层做了两件互为对偶的事：输入端的各种表单，输出端的 Doc + Deck 双件套。

输入端：让 AI 给你递表单，不递问题

需要确定具体参数时，智能体不再用一段话反问，而是在对话里直接给你一个表单，见下图。

你勾选/填写/提交。智能体拿到的是结构化数据，不是"自然语言里大概的意思"。

这一层带来的是确定性，AI 不会把你的回答理解错，你不用揣摩"我该怎么把这件事说清楚 AI 才不出错"，同一类任务的输入路径标准化了，团队成员协作时不再各自摸索。输入越结构化，输出的命中率越高。

输出端：Doc + Deck 让 AI 跑出的洞察直接能用

输出端的逻辑跟输入端对偶。智能体完成任务后，给的不只是聊天里一段 markdown 或者一份要下载的 PPT 文件，而是直接落到统一的可分享形态。Catlaxy AI 的 Share Suite 就是这个判断的产物：Doc + Deck 双件套。

企业内外要交流的内容，90% 落在两种形态。报告滚动读完，承载论证与数据，读者节奏自定（用研报告、数据周报、项目复盘、跨部门同步）；演示翻页讲，承载叙事与节奏，讲者控制节奏（销售提案、融资 pitch、月度同步、培训课件）。两种形态读者不同、阅读节奏不同、信息密度不同，本不该用同一种工具产出。

业内常见做法是：聊完一个洞察，AI 给一段 Markdown 或者一份 PPT 文件。下载、打开、修改、再发出去。中间任何一处要改，要么回去找 AI 重生成（生成的一切要重选），要么自己进 PPT 软件改（脱离 AI 上下文）。Share Suite 在两件事上做了不同的判断：

完整介绍 → Catlaxy Share Suite 详情页

把输入端和输出端放一起看

表单标准化了用户给 AI 的输入，Doc + Deck 标准化了 AI 给用户的产出，中间是智能体的对话上下文 + KnowledgeOS 的业务知识。整个交互形态从"两段散文之间往返猜意思"升级成"结构化输入 → 可见的协作过程 → 可分享的标准化产物"。

企业用 AI 时，能力会落到两种形态：

业内常见做法是做一个超级Agent支持全部的能力（提升使用难度），但我更多看到的是认为Workflow形式已经过时的声音。

我的判断是：这两层不应该是两种产品，而是同一个平台的两层。Catlaxy AI 平台里同时有几十个智能体跟几十个 AI 工具，共用同一份业务知识层、同一套用户体系、同一个交互形态，区别只在使用方式（一个聊，一个跑）。

这套双层架构真正的杠杆是能力可以模块化复用。上一个新工具（比如 PDF 翻译），所有相关智能体（销售/合规/调研助手）都能在对话里调用；上一个新智能体（比如品牌定位策略助手），它立刻能用所有已有工具。每加一块能力，整个平台的可用边界就扩一圈。

但能力之间的复用，还不等于智能体之间的协作。这是下一块拼图要回答的。

前三块解决了"业务知识共享"、"输入输出标准化"、"对话和工具能互调"。但企业实际工作里还有一类协作场景：多个智能体之间的接力。

举一个真实业务里很常见的场景。一家做跨境电商的公司：

如果三个智能体的产出只能各自存在，那协作还是要靠人工搬运：把营销助手的策略复制粘贴到销售助手对话里再交代一遍，把销量数字截图贴给供应链助手再问一次。

协作网络做的就是这一层：一个智能体的产出可以被另一个智能体直接引用做上下文。不是简单的"导入文件"，而是结构化的"我要引用某助手的某次产出的某个章节"。被引用方知道自己被谁引用、引用了什么。引用方在自己的对话里，可以看到上游产出，并基于此继续推进。

平台再好，如果跟企业的其他系统不通，就是另一个孤岛。AI 真正进入业务流，必须要有和外部世界打通的接口。Catlaxy AI 在这一层做了三件事：

这三件事合在一起回答的是同一个问题：企业 AI 不是把所有事都搬进 AI 平台，而是让 AI 平台能把能力推到企业现有的业务流里。

这一年 Catlaxy AI 做的远不止这五块。同时，也扔掉了非常多看起来对的设计，举三个例子：

每件事都做到了一定程度才决定不做。投入是真实的，但留下的判断比做完更有价值。

这些"不做"塑造了我看 AI 平台的视角：每多加一个不连接的功能，工具切换疲劳就多一份。每多加一块跟其他模块不打通的拼图，平台就多一份割裂。判断哪些"看起来对的功能"其实不该做，是平台和工具的根本区别。

如果你正在评估 AI 平台、或者在内部建 AI 能力，下面 5 条可以拿去给候选方案打分。这些不是 Catlaxy AI 独有的标准，任何严肃做平台体系的厂商都会处理这几个维度。

业务原生 Native AI 不是营销话术。它要求对 AI 该不该出现、怎么出现，都应该有清晰判断。

"加更多 AI 工具"不是答案。再聪明的工具，加在一起仍然是工具。让 AI 真正进入业务的关键，不在工具数量，在让它们能在同一个体系里协作。

我的核心看法：一个平台、多个 Agent、共享上下文。用这五块能力组合：共享业务知识层、标准化交互形态、智能体 + AI 工具双层架构、智能体协作网络、与企业系统的连接。