最近几条 AI 行业动态放在一起看，我越来越确定一件事：
未来小公司的竞争力，不只是“用了多少 Agent”，而是有没有一套自己真正拥有的经营记忆和权限系统。
10 月 20 日，Google 发布面向 small business owners 的 Gemini 新工具：一个集中式业务入口，可以处理品牌、财务、客户洞察，并连接 Google Ads、Google Workspace，以及 Shopify、Wix、Zoho、Xero 等第三方应用。
两天前，AI 协作产品 Town 在融资公告里强调了另一个方向：每个公司应该拥有 AI 在业务中形成的 context，并且可以在不同模型提供商之间切换，而不是被锁在单一模型里。
与此同时，OpenCode Console 最近发生安全事件，攻击影响到部分用户，并涉及 API key 暴露和由此产生的实际调用费用。
这三件事看起来分别属于“产品发布、融资、安全事故”，但它们其实指向同一个结构性问题：
当 AI 开始真正连接公司的数据、账户和执行权限时，Agent 已经不再只是聊天工具。它开始进入公司的基础设施层。
一、Agent 的“记忆”和公司的“记忆”不是一回事
很多人第一次搭 AI 工作流，会很自然地把上下文不断塞进某个 Agent：
- 品牌规则；
- 客户信息；
- 商品与库存；
- 成本；
- 广告历史；
- 哪些实验做过；
- 哪些决定已经被否掉。
短期看很方便，因为这个 Agent “越来越懂你”。
但这里有一个很大的结构性风险：如果这些信息只存在于某个平台的记忆里，那么你拥有的不是公司知识，而是平台依赖。
一旦模型更换、产品策略变化、权限失效、API 改版，或者你想迁移到另一套系统，最贵的损失往往不是重新连接几个工具。
真正昂贵的是：
过去为什么这样做，没有地方能完整回答。
二、真正要保存的，不只是结果，还有 Why 和 Evidence
一个普通数据库很容易保存：
“广告暂停了。”
但几年后真正有价值的问题是：
“为什么暂停？当时看到了什么证据？用了什么停止条件？如果环境变化，什么时候可以重新测试？”
所以我现在会把公司记忆拆成两种：
State Memory：现在是什么状态。
例如产品、价格、库存、客户、订单、预算、当前实验状态。
Decision Memory：为什么会变成这个状态。
包括假设、证据、判断、批准人、日期、可逆性和重新评估条件。
前者让 Agent 知道“现在是什么”；后者让未来的 Agent 知道“过去为什么这么决定”。
如果只保留 State，没有 Decision Memory，AI 很容易每隔几周重新提出已经被否掉的建议。
三、我更愿意把 Business OS 拆成 5 层
这和我之前写过的 Trigger → Decision → Action → Audit Log → Human Approval 不完全相同。那篇解决的是“一个自动化流程怎么跑”；这里讨论的是另一个问题：公司状态、权限和记忆应该放在哪里。
1. Owned Source of Truth：自己的事实源
订单、客户、产品、财务、实验、规则，必须有一个你可以导出、迁移和独立读取的事实源。
它可以是数据库、表格、ERP、财务软件或自己的数据仓库，形式并不重要。
重要的是：Agent 不应该成为唯一保存位置。
2. Decision Memory：保存判断，而不是只保存动作
每个重要经营决定至少记录：
- 发生了什么；
- 依据是什么；
- 做了什么；
- 什么结果会证明它错了；
- 什么时候重新评估。
这是最容易被忽略、但最能形成复利的一层。
3. Connector Layer：连接器只负责访问
Gemini 这次把大量业务 App 接入同一个界面，说明未来 Agent 连接 Shopify、Zoho、Xero、Ads、CRM 会越来越正常。
但连接器最好只承担一件事：在明确权限下访问真实系统。
不要让“连接方便”变成“权限无限”。
4. Replaceable Agent Layer：模型和 Agent 都应该可替换
今天最擅长研究的模型，未必最适合明天的财务分析；今天最好用的 Agent，也可能一年后消失。
Town 最近强调可跨主要模型实验室使用不同模型，这个方向本身很值得注意：业务 context 应该跟着公司走，而不是跟着某个模型走。
所以一个健康的架构应该是：
数据和规则稳定，Agent 可插拔。
5. Permission & Capital Gate：最后的边界是权限和钱
当 Agent 只能读数据时，错误通常比较便宜。
一旦它可以：
- 发邮件；
- 改价格；
- 投广告；
- 调用付费 API；
- 采购；
- 提交申报；
风险性质就变了。
OpenCode Console 的事件提醒我们，API key 并不是抽象技术细节。它可能直接等于真实费用和真实权限。
所以我会把权限再拆成三档：
自动允许：读取、整理、分析、草拟。
需要审批：发布、外发、修改重要设置、小额预算动作。
默认禁止自动执行：大额支付、重大合同、税务/法律不可逆提交、核心凭证变更。
四、一人公司最容易犯的错：把“AI 能做”当成“AI 应该拥有”
一个 Agent 可以分析银行流水，不代表它应该拥有银行主账号。
它可以优化广告，不代表它应该拥有无限预算。
它可以更新商品，不代表它应该拥有不受限制的批量修改权限。
这里最重要的判断不是能力，而是：
错了多久能发现？能不能撤销？最坏损失是什么？
这和我之前写的 “能自动化，不等于值得自动化” 是同一条底层原则。
五、一个最小可行的 Business OS，可以只从 6 张表开始
不需要一开始就买复杂软件。对一人公司来说，一个最小系统甚至可以只有：
- Facts：商品、客户、账户、成本等稳定事实；
- Rules：预算上限、审批规则、禁止事项；
- Experiments：假设、变量、成功/停止条件；
- Decisions：重要决定 + Why + Evidence；
- Actions：谁在什么时候做了什么；
- Exceptions：哪些异常需要老板介入。
Agent 每次完成真实动作后，必须 write back。
否则系统会出现一个很危险的状态：AI 知道自己刚做了什么，但公司的事实源不知道。
六、为什么这件事现在特别重要
过去，软件只是工具。你关掉一个软件，公司的大部分知识还在人脑里。
AI Agent 不一样。
它开始同时承担：
- 读取上下文；
- 做判断；
- 执行动作；
- 积累记忆。
能力越集中，迁移成本和错误半径就越大。
所以我越来越认为，一人公司真正应该拥有的，不是最多的 Agent。
而是：
一套任何 Agent 都能接入、任何 Agent 都可以被替换，但公司的事实、规则、决策和审计不会丢失的 Business OS。
结论
Gemini 把更多业务工具连接到 AI，Town 在强调公司拥有 context，OpenCode 的安全事件又把 credential 和费用风险摆到台面上。
这些变化共同说明：
下一阶段的 AI 公司，不只是“谁能自动化更多”，而是“谁能在自动化越来越强的同时，仍然牢牢拥有自己的数据、记忆、权限和资本边界”。
工具可以租。
模型可以换。
Agent 可以换。
公司的经营记忆，最好不要跟着任何一个工具一起换。