为什么要做自己的 AI Agent 平台？

关联文档：[[../../../_archived/ai-native/ai-native-new/003 上下文工程]]、[[../../../_archived/ai-native/ai-native-new/007 AI Native 工作台]]、[[../../../_archived/ai-native/ai-native-new/008 企业 AI 原生能力底座蓝图]]

通用 Agent 很强，但它不认识我的公司

我自己是通用 Agent 的重度用户：Codex、Claude Code、WorkBuddy 都在日常用，写代码、处理文档、跑复杂任务，它们几乎是当下最好的个人 AI 助手。

但用得越深，我越清楚它们在公司场景下的边界：拿不到企业内部数据，不理解指标口径和业务流程，进不了审批体系，也不知道公司里谁能看什么、不能看什么。而且员工个人用得越深入，企业的数据外流和使用失控风险反而越大。

这就是我推动公司做自己 AI Agent 平台的起点。这个平台不是再做一个单点 AI 工具，而是打造公司级 AI 原生能力底座：以统一入口，把 AI 能力、内部数据、数据分析系统、业务协同系统、员工经验、知识资产和业务流程连接起来，逐步形成面向全公司的智能协作体系。

目标很明确：让 AI 不只是个人提效工具，而是成为公司创新、知识沉淀、协同办公和安全治理的新基础设施。下面分享我思考这件事的八个方向。

一、集体创新平台

我希望平台能把员工的想法、业务经验、问题反馈和 AI 生成能力结合起来，形成更低门槛的创新入口：围绕经营、门店、项目、产品、流程、客户服务等场景，任何人都可以提出问题、生成方案、验证想法。

用通用 Agent 时我观察到一个现象：优秀的提示词、分析方法和业务模板，都留在员工的个人账号里，人一走就带走了。而在自己的平台上，这些好用法可以从个人使用中沉淀出来，逐步变成团队和公司的通用能力。

说白了，就是把个人灵感转化为团队资产，把零散尝试转化为组织创新能力。

二、知识沉淀体系

公司内部的知识分散在制度文档、业务系统、历史报表、项目资料、聊天记录、审批记录和员工经验里，传统方式下难检索、难复用、难持续更新——这是我见过的最普遍的老问题。

平台可以逐步连接内部知识库、数据分析系统和业务协同系统，让 AI 帮员工查找、理解、总结和复用公司知识。这些内部上下文，恰恰是通用 Agent 天然拿不到的。

再往后走一步：员工每一次高质量问答、每一套成熟分析方法、每一个可复用工作流程，都能沉淀为知识资产、技能模板或业务助手。知识就这样从“散落在人和系统里”，变成可查询、可复用、可持续进化的组织资产。

三、上下文资产飞轮

这是我个人认为最本质的一条。AI 的效果上限，本质上由上下文决定：你给它多少准确的企业背景，它就给出多贴合业务的回答。

通用 Agent 的上下文随会话结束就消散了，还留存在厂商的服务器上。而自己的平台可以把指标口径、业务术语、历史问答和使用反馈，持续沉淀为企业专属上下文，让 AI 的每一次服务都建立在前一次的积累之上。

用得越多，AI 越懂这家公司——这就是“租用能力”和“建设能力”的本质区别，也是上下文复利：在企业内部持续积累，越用越聪明。

四、智能协同工作

我对这个平台的定位，从来不是个人 AI 助手，而是面向团队协同的智能工作空间。

通过连接业务协同系统，AI 能进入组织、人员、审批、文档、消息、流程等协同场景；通过连接数据分析系统，AI 能围绕经营指标和业务数据做分析与辅助决策。

更重要的是从“会答”走向“会办”：在受控边界内，AI 可以直接发起审批、创建工单、写回业务系统，让任务在平台内闭环。通用 Agent 只能操作员工个人的电脑环境，进不了企业系统的执行层。

未来团队在同一个 AI 工作空间里，就能完成问题分析、资料整理、方案生成、任务推进、流程辅助和结果沉淀。让 AI 从个人工具升级为团队协作伙伴，跨部门协同效率和业务响应速度自然会起来。

五、数据驱动决策

自研最关键的优势，是和公司内部数据、系统打通。Codex、Claude Code、WorkBuddy 很难直接理解公司的经营数据、指标口径、业务流程和权限体系——它们能处理的，基本只有员工手工喂进去的信息。

连接数据分析系统之后，AI 可以基于公司真实数据做查询、分析和解释，帮管理层和业务人员更快发现问题、理解趋势、形成判断。

我的经验是：让 AI 基于真实业务数据辅助决策，而不是只基于人工输入和通用知识回答问题，这才是数据驱动的起点。

六、安全可控体系

AI 进入企业内部，安全和可控是前提。自研平台可以统一管理账号、权限、模型配置、数据访问范围、工具调用边界和使用规范。

相比员工自行使用外部通用 Agent，自研平台能把数据和系统的接入放在公司可控环境内：权限可控、过程可追踪、能力可管理、风险可收敛。通用 Agent 越强大，这一层治理就越不能缺席。

一句话：在保障安全和合规的前提下释放 AI 能力，避免数据、权限和工具使用失控。

七、成本与模型主权

我算过一笔账：通用 Agent 按席位订阅，全员铺开就是一笔随人数线性增长的固定开支。自研平台按实际调用计费，还可以做模型路由——简单任务走小模型，复杂任务才调大模型，把预算花在真正需要的地方。

同样重要的是模型主权。模型市场半年一次洗牌，今天最强的模型未必是明天的最优解。平台把模型层抽象出来之后，企业可以自由切换、混用和比价，不被单一厂商的产品节奏和定价策略绑定。

核心就一条：把 AI 的成本结构和模型选择权握在自己手里，而不是交给外部厂商。

八、企业 AI 能力底座

长期看，我希望这个平台成为公司 AI 能力的统一承载底座。

它承载的不只是某几个功能，而是沉淀模型接入、数据连接、系统连接、技能管理、权限控制、流程编排、知识管理和应用扩展能力。之后不同部门、不同业务场景，都能基于这套底座快速构建自己的 AI 应用。

这件事的本质，是把 AI 建设从单点项目，升级为可持续扩展的企业能力平台。

结语

最后说说我的整体判断。通用 Agent 和自研平台不是替代关系：前者解决个人效率问题，后者解决组织能力问题——数据连接、权限治理、知识沉淀和流程协同，必须掌握在企业自己手里。

当所有公司都能买到同一批通用 Agent，工具本身并不构成优势。真正的竞争力，是通用 AI 能力与企业独有的数据、流程和上下文相乘。

通用 Agent 可以成为平台上的执行引擎，但承载它们的底座，需要企业自己建设。

附：技术实现的一点思路

落地层面，我的选择是优先基于 OpenCode SDK 搭建基座：通用性强，不绑定任何模型服务商，可以自由切换和混用模型。前面讲的“模型主权”，在实现层面首先就是 SDK 选型问题——选错了底座，等于在代码层面就被锁死了模型选择。

如果观众对“如何从零做一个简单的 AI Agent 平台”感兴趣，我后续可以单独出一期，拆解最小可行架构。

Comments

Post a Comment

Popular posts from this blog

How to turn off Sass warning prompts in Nuxt.js projects

Background of the Issue When developing projects with Nuxt.js, it’s common to encounter a large number of Sass-related warning messages in the console. These warnings mainly include: Warnings about the order of mixin declarations. Warnings about the use of Legacy JS API. Although these warnings do not affect the operation of the program, they can degrade the development experience by cluttering the console. Today, we will explore how to elegantly address this issue. Solutions 1. Disable Warnings via Configuration In the nuxt.config.js file, we can modify the Sass configuration to suppress these warning messages: export default { build: { loaders: { scss: { sassOptions: { quietDeps: true , // Suppress warnings from dependencies logger: { warn: function ( message ) { return null ; // Silence warning messages }, debug: function ( message ) { return null ; // Silence ...
Read more

Configuring SSH Access to a Docker Container via an Alternative Port

Configuring SSH Access to a Docker Container via an Alternative Port If you want to configure SSH access to a Docker container using an alternative port, such as port 6666 , follow the steps below carefully. This guide assumes that you have administrative access to your Docker host and are familiar with basic Linux commands. Step 1: Run the Container with SSH Service Start by running a new container from your image with port 6666 on the host mapped to port 22 inside the container: sudo docker run -it -p 6666 : 22 --name ssh-container testimage Make sure to replace testimage with the actual name of your Docker image. The --name option gives the container a specific name for easier management. Step 2: Install OpenSSH Server in the Container Once inside the container, update the package list and install the OpenSSH server: apt-get update && apt-get install -y openssh-server Step 3: Set the Root Password Set a password for the root user, which will be required when l...
Read more

Quickly Set Up a Cloud Database Using MongoDB Atlas

Quickly Set Up a Cloud Database Using MongoDB Atlas MongoDB Atlas is the official fully managed cloud database service from MongoDB, simplifying the deployment, management, and scaling of MongoDB in the cloud. This article will guide you on how to quickly create a MongoDB Atlas cluster and set up basic connection configurations. Creating a MongoDB Atlas Cluster Sign Up & Log In If you do not have a MongoDB Atlas account yet, head over to MongoDB Atlas to sign up. After logging in, click on “Build a Cluster” to start creating a new cluster. Select Cluster Configuration To meet the needs of most development and testing scenarios, you can choose the free tier (M0) shared cluster, which is usually sufficient for small applications or personal projects. When choosing a cloud provider, select based on your preference. Here we chose Azure, but AWS and GCP are also great choices. Specify Geographic Location For geographic location selection, choose according to your u...
Read more