今年年底，很多企业的 AI 团队可能会同时收到两张账单。
第一张是研发账单。
内部做了半年 AI 助手，刚补上文件解析、工具调用和知识库，WorkBuddy、飞书豆包伙伴助手这类通用工具又更新了一轮。产品能力没拉开差距，维护范围却越来越大。
第二张是模型账单。
过去只有少数人尝鲜，费用可以算创新预算。等销售、运营、产品、研发都把 AI 放进日常工作，调用量会进入管理视野：谁在用、用了多少、为了什么任务、产生了什么结果，都会变成财务和管理问题。
两张账单放在一起，会逼着企业重新回答一个问题：我们到底为什么要做 AI 产品？
我的判断很激进：企业自建通用 AI 产品或 AI 平台的窗口可能只剩半年。
这里的“半年”是一个产品预测，不是经过行业数据验证的结论。它也不是说半年后企业不用做 AI，而是说，企业必须尽快停止复制通用工具，把资源转向两项真正属于自己的基础设施：
- 给 AI 提供私有数据和上下文；
- 给团队分配 Token，并管理预算、权限和产出。
到年底，企业 AI 团队可能不再像一家内部软件公司，更像企业的上下文供应商和Token 治理者。
自研 AI 产品正在变成一场追赶赛
过去，自研企业 AI 助手看起来很合理。
通用产品不懂内部业务，也接不上企业系统。团队做一个聊天入口，挂上知识库，再连接几个业务工具，很快就能做出可演示的版本。
问题是，这条产品线没有自然终点。
模型在更新，桌面操作、浏览器控制、文件处理、长期任务、记忆、插件、连接器和安全机制也在更新。每补上一块能力，后面都跟着兼容、监控、权限和维护成本。
这就是 Harness。它不是一个聊天框，而是承接上下文、工具调用、任务执行、记忆、恢复和安全控制的整套运行框架。
对 WorkBuddy、飞书豆包伙伴助手这样的产品来说，Harness 是主航道。它们可以把同一项投入分摊给大量客户，并持续吸收模型厂商和办公生态的新能力。
对多数企业来说，Harness 只是支撑内部业务的基础层。团队既没有相同的人才密度和投入强度，也很难要求老板对一个长期追赶、短期难见差异的项目保持耐心。
这不是内部团队不够努力，而是比较对象错了。
企业自研产品真正应该回答的，不是“我们能不能做”，而是三个问题：
- 这项能力是否只有我们拥有？
- 外部成熟工具是否无法提供？
- 持续投入后，能否沉淀成企业自己的复利资产？
通用对话、模型接入和基础工具调用，很难同时通过这三个问题。私有上下文可以。
第一件事：成为企业 AI 的上下文供应商
企业没有必要比通用工具更懂怎么做聊天框，但必须比任何外部工具更懂自己怎么做生意。
客户数据在哪里，业务指标如何定义，什么情况下可以调价，异常订单由谁审批，哪些经验只存在于老员工脑子里，哪些信息只能被特定岗位读取——这些才是企业 AI 与个人 AI 的分界线。
所以，给 AI 提供上下文，不是把一批文档上传到知识库。
一份真正可用的企业上下文，至少要回答五个问题：
- 来源：这条信息来自哪个系统、文档或负责人？
- 时效：它现在是否仍然有效，何时需要更新？
- 权限：谁可以让 AI 读取，能否跨部门使用？
- 场景：它服务哪个任务，在什么条件下生效？
- 反馈：AI 使用后是否提高了任务成功率，错误如何回流？
私有数据、SOP 和知识只是原材料。企业 AI 团队要做的，是把它们加工成 可调用、可追溯、可授权、可更新 的上下文。
这个角色更像上下文供应商。
上层工具可以更换，模型也可以更换，但企业对数据语义、业务规则和流程边界的解释权不能外包。否则，企业看似采购了更强的 AI，实际上仍要在每个工具里重新整理一遍知识、权限和流程。
第二件事：成为企业 Token 的预算管理者
当 AI 从个人尝鲜变成团队生产工具，Token 就不再只是技术账单上的一行数字。
它会变成一种需要分配的组织资源。
但“Token 分发”不能只理解为统一充值，再给每个人设一个额度。真正要管理的不是谁多用了十万 Token，而是每项任务的成本与结果。
这套治理至少包括六件事：
- 身份：员工、岗位、部门和 Agent 使用什么凭证；
- 额度：个人、团队、项目分别有多少预算；
- 路由：什么任务使用什么模型，何时选择便宜模型；
- 归属：成本计入哪个部门、客户或业务项目；
- 风险：哪些数据不能发送，哪些动作必须人工确认；
- 效果：这笔消耗是否完成任务，是否减少人工，是否需要返工。
统一入口的价值也在这里。
它不只是帮企业拿到一个更低的采购价，更不是为了把所有员工锁进同一个聊天页面。它要让身份、权限、预算、模型路由、审计和业务结果进入同一套管理体系。
如果只看总 Token，团队最容易做的是限额；如果能看到成功任务成本，团队才可能真正优化。
前者是在控制员工少用 AI，后者是在推动企业把 AI 用得更值。
上下文与 Token，其实是一套系统
表面上看，私有上下文属于知识管理，Token 属于成本管理。
但两者必须放在同一个闭环里。
没有企业上下文，员工只能拿通用模型反复解释背景。输入越来越长，结果仍然不稳定。Token 消耗了，业务知识没有沉淀。
没有 Token 治理，再好的上下文也很难规模化。企业不知道哪些场景值得投入，哪个模型性价比更高，哪份知识正在制造错误，也无法在费用或风险异常时及时停止。
完整链路应该是：
企业数据、知识与 SOP → 按任务组装上下文 → AI 执行 → 业务结果 → 成本与质量评估 → 修正上下文和路由
在这条链路里，企业真正积累的不是调用次数，而是三类资产：
- 哪些上下文能帮助 AI 完成特定任务；
- 哪种模型和工作流能以合理成本完成任务；
- 哪些错误会重复发生，应该修改知识、流程还是权限。
通用工具负责把模型能力送到员工面前。企业负责让这份能力理解业务，并在预算内产生结果。
这才是双方合理的分工。
“半年窗口”关掉的是什么
半年后，企业当然仍然可以自建 AI 产品。
但届时要证明“为什么不直接采购”，会越来越难。通用工具会继续补齐基础能力，员工也会形成使用习惯。内部平台如果仍然只是另一个聊天入口、另一个知识库和另一组模型切换按钮，就很难获得下一轮预算。
所以，所谓半年窗口，关掉的不是企业使用 AI 的机会，而是把复制通用 Harness视为合理战略的窗口。
未来半年，企业 AI 团队更应该完成三张清单。
第一张是停止清单：哪些通用能力不再追赶，哪些重复入口不再建设。
第二张是采购清单：哪些成熟 Harness、模型和连接能力直接采购，并保持可替换。
第三张是自建清单：哪些私有数据、业务语义、SOP、权限规则、评估方法和预算机制必须掌握在企业手里。
然后，不要再做一个覆盖全公司的宏大平台。选三个高频、边界清楚、结果可衡量的工作流，验证三件事：
- 接入私有上下文后，任务成功率是否提高；
- 更换工具或模型后，企业资产是否仍然可用；
- 使用规模扩大后，能否看到每个成功任务的真实成本。
如果这三件事成立，企业建设的就不是另一个 AI 壳子，而是一套能够随工具变化继续积累的基础设施。
企业不需要再造一台发动机
企业建设内部系统时，很容易沿用过去的信息化经验：市场出现新技术，就做一套内部平台把它管起来。
AI 改变了这个顺序。
通用产品迭代太快，模型和 Harness 都会持续变化。企业很难靠复制外部产品建立优势，也没有必要把最稀缺的人投入长期追赶。
企业真正应该掌握的，是任何外部 AI 进入公司后都必须使用的上下文，以及每一次调用都绕不开的预算和治理规则。
一个决定 AI 能不能理解企业，一个决定 AI 能不能在企业里规模化。
到年底回头看，也许企业做 AI 的终局并不是做出最好的 AI 产品。
而是让任何足够好的 AI 产品，都能安全地使用企业上下文，并在清晰的 Token 预算里，为业务完成任务。