Sakana Aquarium：企业 Agent 要跑起来，先把组织规则说清楚

工具2026 年 10 月 26 日发布小智

企业里的 AI，正在从回答问题走向执行任务。但一句“帮我处理这笔订单”，背后可能同时牵涉客户信用、库存口径、价格权限和审批责任。模型能读懂这句话，不代表它已经理解这些条件。

2026年10月23日，Sakana AI 发布 Sakana Aquarium，将组织知识、本体、治理与 Agent 运行放进同一平台。它提出的方向值得关注：把企业判断所依赖的前提整理成可复用基础设施，让不同 Agent 不必每次重新猜测“这家公司如何做事”。

一、真正难的，是同一个词在不同部门里含义不同

以一个假设的订单场景为例。销售看到“有库存”，可能理解为可以报价；仓库的库存包含待质检货物；财务则关心货权是否清晰、客户是否欠款。如果 Agent 只取到其中一张表，答案可能语法完整、数字准确，却给出了业务上不能执行的承诺。

这类问题不能全部交给提示词解决。提示词可以提醒模型注意信用风险，却不能替企业决定哪张表是信用额度的权威来源，更不能自动消除“可售库存”和“账面库存”的口径差异。企业需要明确实体、关系、状态和规则，再让模型在这套共同语言里工作。

Aquarium 所采用的本体，可以理解为这份共同语言的结构化表达。它不只是给文档加标签，而是将知识、规则、数据及其关系组织起来，作为判断与行动的基础。这个设计的意义在于：下一位 Agent 接手另一条业务流程时，可以复用既有定义，而不是重新制作一套互不兼容的解释。

根据 Aquarium 产品介绍，平台连接既有数据，通过本体组织信息，并用工作流表达业务步骤；人工审批可以嵌入其中。具体连接与同步方式，需要针对目标数据环境设计。发布说明还列出权限、执行前批准，以及判断依据和结果记录等治理能力。

这让企业评估 Agent 的方式发生变化。过去演示常常围绕一个问题能否答对；进入业务系统后，至少还要问：

假设一名采购 Agent 找到了更便宜的供应商。真正有价值的工作流，不应停留在“推荐成功”，也不应直接替企业下单。它需要检查供应商准入、交付能力与预算，再把需要负责人的判断交出去。采购建议和采购承诺之间，应有一条清楚的责任链。

企业可以很快拥有销售、客服、财务等多个助手，却未必因此形成协作。如果客户编号无法对应，价格规则各有一份，审批记录分散在聊天窗口里，Agent 数量越多，维护负担反而可能越高。

因此，Aquarium 的商业价值更适合从复用率理解：一个流程中整理好的客户定义、权限边界和数据连接，能否被下一个流程使用？规则变更后，是否能集中更新，而不是逐个修改提示词？这些问题比演示中多完成了几个任务，更接近长期运维成本。

从组织角度看，这也意味着项目不能仅由 AI 团队推进。数据团队提供可靠来源，业务负责人解释例外，安全团队明确权限，运营人员提供失败案例。平台可以承载规则，但规则的所有者必须是企业自己。

老员工知道哪些客户可以先发货、哪些异常必须升级处理，这些知识往往并未写进系统。把它们结构化时，企业会发现：不同负责人可能对同一问题给出不同答案。

这不是简单的数据清洗，而是管理问题的显性化。若业务口径尚未统一，贸然让 Agent 执行，可能只是把原来的模糊判断自动化。反过来，梳理规则也可能成为项目最有价值的产出，即使第一阶段只有少量动作被自动执行。

还要区分“更新能被反映”与“任何时候都绝对实时”。业务源系统的更新频率、同步失败处理、权限变化传播速度，都需要在落地时验证。产品架构提供了方向，实际效果仍取决于连接质量和流程设计。

更务实的试点，是选择一个输入明确、结果可核对、失败可以回退的流程。例如先让 Agent 收集异常订单资料并给出处理建议，再逐步开放低风险操作。

验收指标可以分成三组：业务上看处理周期与返工率；治理上看证据是否完整、批准是否有效；运维上看规则修改后能否稳定运行。还应主动测试过期资料、权限撤销、重复任务和工具失败，而不仅是理想输入。

Sakana 在发布说明中提到，既有金融项目的实施经验推动了平台化，但这些项目不能直接等同于 Aquarium 已经取得的客户部署成果。对于新平台，真正值得持续观察的，是后续具体案例如何证明复用、治理和运行可靠性。

企业 Agent 的竞争，最终会落在“能否持续承担一段可追责的工作”上。Aquarium 给出的启发是：在追求更多自动执行之前，先让组织对数据、规则和责任拥有一致答案。

发布 Sakana Aquarium https://sakana.ai/aquarium-release/

Aquarium 产品介绍 https://sakana.ai/aquarium/

文章版权归作者所有，未经允许请勿转载。