你的 AI 懂政策，但它知道谁有权批准这笔订单吗？

员工询问团队能否购买一台替换用笔记本电脑。AI 助手找到采购政策，并给出合理答案。但实际决定仍然取决于预算、供应商、员工所属部门，以及谁有权批准这笔具体订单。

2026 年 10 月 23 日，Sakana AI 宣布推出 Sakana Aquarium，一个围绕组织数据和规则来构建、运行及治理智能体的平台。这家日本 AI 公司描述了一套连接信息含义与关系的本体、托管智能体运行时，以及覆盖访问、审批和执行记录的治理机制。官方公告。

有用的问题，是答案与获授权行动之间发生了什么。Aquarium 的提议，是为这一缺口建立共享结构，让每个新智能体不必重新摸索公司所说的客户、采购或批准究竟意味着什么。

Sakana AI 早期的 TinySwallow 浏览器聊天界面，用于说明其从模型走向产品的背景。这不是 Aquarium。图片：Sakana AI，采用 Apache License 2.0。已调整尺寸，未经裁剪。

同一个词，在不同系统里可能有不同含义

多数组织已经在某个地方保存了智能体所需的信息。电子表格列着预算，文档解释采购规则，应用记录订单状态。困难之处，是知道哪些内容指向同一件事，以及在作出决定的那一刻，哪个来源才具有权威性。

例如，“已批准”可能指经理在邮件中同意，采购申请通过财务检查，或供应商已经接受订单。这些状态彼此相关，却不能互换。把它们当同义词的智能体，可能说出听起来正确的答案，却采取错误的下一步。

本体，是对这类含义和关系的结构化描述。根据 Aquarium 的介绍，它将组织知识、规则和数据连接起来，让智能体可以结合上下文使用。产品页面还说明，连接与同步会针对目标数据来源进行设计。平台说明。

我们的理解是，困难工作被移到了更可见的位置。仍然必须有人决定一个状态意味着什么、哪个来源拥有它，以及何时发生改变。让这些决定明确下来，可能很有价值，因为其他流程可以复用，而不用在另一段提示词里编码一个略有差异的定义。

这与其说是把更大的文件柜交给聊天机器人，不如说是共同约定一张地图。地图不能替代现实，但能更容易辨认一个问题涉及哪份记录、哪条规则和哪位负责人。

产品所述方向的原创解释图：共享定义将信息与受治理的工作流程连接起来。

一项采购请求，揭示为什么仅靠检索不够

设想一个替换笔记本电脑的示例请求。有用的流程应识别员工、适用预算、获批准供应商，以及当前采购状态，再确定所需审批路径，而不是把一般政策段落当成购买许可。

如果预算记录在请求发起后发生变化，流程就需要明确如何使用新值；如果经理不在，需要知道其他人能否批准；如果供应商报价过期，早先批准可能已经不再涵盖当前订单。

这些主要不是语言生成问题，而是责任归属、时间和权限问题。模型可以帮助理解请求，但应用必须把这种理解连接到正确记录与获准操作。

Aquarium 的公告描述了访问控制、执行前审批，以及连接判断依据与结果的记录，还提到了跨智能体复用数据和本体定义。这些都是值得在试点中评估的产品承诺，却不能因此假设每个组织的采购流程都已经被覆盖。治理与托管智能体。

小型初始项目，应让一条这样的决策路径从头到尾都能被理解。这比连接公司所有文档，再提出宽泛问题，更能揭示实际情况。目标是一项输入、负责人和结果都可以检查的具体任务。

客户例外，需要规则，也需要理由

第二种场景，是处理企业客户的例外安排。假设合同有标准续约日期，但销售人员承诺了不同安排。只读最新邮件的智能体，可能忽略合同；只读合同的智能体，又可能忽略已经获授权的例外。

有用的系统应区分建议与已批准变更，并让必须作出决定的人能够取得支持信息。目标不只是选择最新文字，而是连接相关记录及其状态和权限依据。

共同定义可以在这里复用。如果一个流程理解客户合同状态，另一个理解计费，它们就不应为同一次续约发明不同含义。共享基础，可以在组织增加更多智能体时减少不一致。

但好处取决于基础的质量。错误关系可以和正确关系一样被高效复用。因此，团队应审查定义及其更新路径，而不只是看演示中智能体生成的答案。

对于考虑类似平台的读者，最有用的问题应当具体：如果把相关含义、状态和权限连接起来，哪个决策会改善？如果没人能指出那个决策，项目可能只是在收集信息，却没有清晰的运行目的。

世界变化时，可复用流程仍然需要负责人

Aquarium 产品页面描述了用 YAML 表达的工作流程，包括信息引用、AI 判断、函数执行和人工审批，也解释了相连信息的更新可以反映到本体中。工作流程与同步。

这是有用的方向，因为过程可以作为一串决策和行动来审查。人可以询问审批应该放在哪里、哪个函数执行操作，以及信息缺失时会怎样。不应只有生成这个流程的模型，才理解它。

不过，一次更新抵达系统，不等于组织已经同意如何理解它。新政策可能只适用于某个日期之后发起的请求；变更后的客户记录，可能在影响敏感操作前需要审查。答案由周围的业务规则决定。

因此，责任归属应在两个层面上明确。有人维护数据连接并发现失败；另有人，或小团队里的同一个人，负责业务定义并决定何时修改规则。如果没有这些责任，同步可能只会让过时假设传播得更快。

这些是评估问题，并非针对某个客户部署的成果主张。目的是把平台概念，与企业能够认出的任务联系起来。

从一项能理解其错误的操作开始

Aquarium 官方网站目前提供产品介绍与咨询入口，但并未证明存在公开的自助价格，或面向所有客户统一启用的日期。因此，初次讨论围绕具体操作展开，比承诺让整家公司转向智能体更有用。介绍与联系。

实际准备步骤可以这样安排：

1. 选择一项重复操作，例如在采购请求到达审批者前进行检查。
2. 找出原始记录、拥有各个值的系统，以及负责各条业务规则的人。
3. 写出重要状态，包括信息缺失、例外，以及必须停止的请求。
4. 定义智能体可以准备哪些行动、可以执行哪些行动，以及两者之间所需审批。
5. 与目前处理这些工作的人员一起，评估普通和困难示例。
6. 扩展到其他操作之前，检查执行记录和更新路径。

这种方式让试点更容易评判。团队可以比较汇集信息的完整性、建议路由的正确性，以及审查者的负担，也能发现系统是否自信地推进了原本应该等待的请求。

第一个有用结果，可能是更好的准备，而不是自动执行。汇集相关信息并找到合适审查者，就可能消除真实瓶颈，同时也为日后是否适合增加自主性建立更清楚的基础。

建议的评估顺序。扩大智能体数量，应以一条已经有效运行的决策路径为基础，而不是用数量替代它。

Sakana 的企业经验，解释方向而非证明结果

Sakana AI 的公告，将 Aquarium 与公司在金融服务等要求准确性和可问责性的领域实施 AI 的经验相联系。公告描述了反复连接数据、整理术语和判断标准所投入的工作，并将 Aquarium 定位为共同基础，避免每个项目重新构建。产品背景。

这一背景有助于解释团队为何选择将这个问题产品化，但不应与公开衡量的 Aquarium 成果混为一谈。此前涉及 Sakana AI 的合作，并不会自动成为 Aquarium 客户案例；一次狭窄部署成功，也不是所有操作都能轻松迁移的证据。

接下来应关注运行层面的证据。选择了哪项任务？系统需要什么信息？还有多少工作留给人？错误或不完整案例如何处理？这些细节，会比笼统宣称智能体提高了生产力，更有助于理解案例。

产品未来方向包括将运行中的纠正与判断纳入持续更新，以及协助构建智能体。这提出一个重要设计问题：如何区分建议改进与对公司规则已经批准的变更？答案的重要性，不亚于快速生成工作流程的能力。

对于采用智能体的企业，最有力的成熟信号，可能是安全修改规则并解释影响的能力。如果一个基础系统只有在演示当天才让人看得懂，随着政策、人员和系统变化，它就会变得难以维护。

有用的企业智能体，需要知道答案授权了什么

Aquarium 值得关注，因为它把组织含义与控制机制视为智能体平台的一部分。这比找到一段看似合理的文字要求更高，却也更接近企业真正需要完成的工作。

试点要问的，不是智能体听起来是否熟悉政策，而是正确的信息能否到达正确决策，合适的人是否授权下一步，以及组织能否在事后解释发生了什么。

来源

• Sakana AI：Aquarium 公告，2026 年 10 月 23 日。
• Sakana Aquarium 平台概览，于 2026 年 10 月 26 日查阅。

保留决策背后的材料

Telli.sh 是将获授权来源材料，与审查过的笔记一起保存的一种选择。创建笔记工作区。