Ankole 的 Agent OS：让团队共享状态、权限与组织记忆
来源：Li（Boris Ding）的 X 帖，帖文分享了 X Article 《为团队构建真正的 Agent OS：来自 Ankole 的工程实践》，发布于 2026 年 11 月 4 日。文章注明这是《Building a Real Agent OS for Teams: Lessons from Ankole》的中文翻译版，遇到歧义应以英文原文为准。本文是对该设计文章的结构化整理，不代表 Ankole 已经公开了完整产品、代码或企业部署结果。
Claude Code、Codex 和其他 Harness 在个人电脑上已经可以连续执行数小时的任务。但把“一个人配一把键盘”的循环直接搬到销售、客服、采购、财务和法务共同使用的公司里，问题很快会从模型智商转向系统设计：谁能看到什么，哪个数字是权威的，修改如何合并，经验怎样留下，以及 Agent 在后台运行时如何被叫停和恢复。
Ankole 文章的核心判断是：团队 Agent 不是给聊天窗口加一个机器人，而是要有一套面向多主体组织的操作系统原语。 人和 Agent 应该操作同一批持久业务对象；权限、状态、记忆和执行环境则由底层系统统一管理。
为什么单用户方案会失效
文章先指出两种常见的“团队化捷径”：给单用户 Harness 套上三栏网页界面，或者把一个共享机器人放进公司群聊，再接上 MCP。它们适合演示和透明度很高的小团队，却很难承载真实组织里的长期状态。
聊天不是业务状态
订单台账、供应商比价和内部工具的生命周期远长于一段对话。如果工作结果只停留在聊天流、CSV 或 JSON 文件夹里，多条会话会各自生成“最新版本”，最终出现互相冲突的副本。每次核对都要重新把历史压进提示词，既浪费上下文，也不断消耗模型调用。
系统提示词不是访问控制
在共享机器人提示词中写一句“不要泄露机密”，无法替代代码级权限。财务、采购和法务的可见范围不同；提问者、Agent 和当前房间之间需要求权限交集。管理员撤回一份源文档后，引用它形成的派生记忆也应当随之隐藏。
远端 API 会丢掉业务语境
Agent 如果只能从外部 API 取得裸数字，就不知道谁录入、按什么口径定义，也无法使用 ripgrep、DuckDB、Python 和编程 CLI 等成熟的本地文件工具。把大量分页 JSON 全部塞进上下文，既贵又难以分析；让数据以受权限控制的文件视图出现，反而能利用标准工具在上下文之外完成过滤和聚合。
Ankole 的总体形态
文章描述的工作空间包含两层：
Agent-first 工作空间
页面 · 带类型数据表 · 内部应用 · 群聊
↓
多用户操作系统内核
状态控制面 · 权限图 · 封存凭据 · 会话路由
↓
按需 Linux 沙箱
Bash · Python · DuckDB · 浏览器 · Claude Code / Codex
Shopify、ERP、Jira 等外部系统仍然是各自领域的权威来源。Ankole 的设想是通过受控连接器同步状态并管理回写，而不是把所有外部系统粗暴替换成一个新的聊天数据库。
1. 共享状态：从聊天记录变成业务对象
真实工作通常以碎片进入系统：客服频道的退换货消息、邮件附件中的报价表、广告 CSV、店铺订单 Webhook。Agent 需要做的是隐式 ETL：抽取字段、转换类型、按业务键关联，再更新共享记录。
带类型的数据表
Ankole 把类似 Airtable 的结构化数据表直接放进工作空间。表不是聊天结束后生成的静态导出，而是人和 Agent 共同维护的实时状态：人可以直接修正一个已知数字，Agent 则随着事件到达持续提取和关联。
文章提出三条并发写入规则：
| 规则 | 作用 |
|---|---|
| 组合业务唯一键 | 让超时重试变成幂等更新，避免重复行 |
| 按字段更新与版本校验 | 客服改备注时，不会被另一个 Agent 用整行覆盖；过期写入需要重读后重试 |
| 只有数值真正变化才发事件 | 相同库存被重复同步时，不会触发无限 Webhook 循环 |
这组规则解决的不是模型推理问题，而是数据系统的基本并发语义。Agent 可以提出写入，但最终业务对象仍需要可审计、可回滚和可验证。
可塑应用与 Fast Path
新问题、模糊目标和异常根因适合走 Slow Path：唤醒模型调查、写代码和构建工具。当同一类核对已经被反复验证，文章建议把它编译成可塑的内部应用或定时 Automation Job，直接连接数据表和受控连接器运行。
这样，熟练采购和 Agent 一起确认到岸成本公式后，后续点击可以直接执行经过测试的代码，不必每次重新调用前沿模型。它把经验从“某个人的提示词”变成团队可以共同使用的工具，同时降低重复任务的 Token 成本。
2. 权限委托：借鉴 UNIX setuid
应用代码究竟用谁的身份读取和写入数据，是团队 Agent 的关键问题。全局管理员权限过大，完全使用点击者权限又无法完成跨角色工作。
文章用 UNIX 的 setuid 做类比，并区分三种执行模式：
| 模式 | 权限主体 | 适用场景 |
|---|---|---|
caller | 点击应用的用户 | 交互式查询和修改 |
owner | 任务所有者 | 无人值守的定时任务和自动化 |
setuid | 经批准的应用所有者 | 允许客服提交申请，但不允许客服读取整张敏感总表 |
所有者委托本身是高价值提权目标。因此，启用委托和发布代码变更都要经过所有者明确批准；所有者账号停用时，委托关系立即撤销。这个设计把“能不能调用”与“调用时以谁的权限执行”分开处理。
3. 多主体与 A2A：让专业 Agent 保留自己的边界
文章将员工和 Agent 都视为独立的 Principal，放进同一张内核权限图。它区分两类角色：
- 个人助理：与员工一对一，逐渐学习个人的优先级、偏好和工作方式。
- 专职 Agent：例如
@legal、@finance，拥有受限档案库、领域规则和服务账号，可被多人呼叫。
普通对话可以按“提问者 ∩ Agent ∩ 房间受众”检查可见范围。但采购找法务审合同的时候，采购本人可能无权查看历史诉讼卷宗，而法务 Agent 又必须能够读取这些卷宗才能给出意见。文章用异步 A2A 会话处理这个边界：个人助理只把合同草稿的“仅评论”权限交给法务 Agent，法务在自己的身份和权限里查阅判例，最后把修改意见写回共享草稿，而不把原始案卷交给采购。
A2A 载荷和共享文档都应标记为不可信数据，不能覆盖接收方的系统规则。控制面还需要记录每次请求和回复、限制检索范围，并在对话切换到包含外部供应商的房间时重新验证受众集合。权限不是一次授予后永久有效的标签，而是每次召回上下文时都要重新检查的条件。
4. 凭据与外部系统：同步状态，隔离密钥
文章对外部 SaaS 连接提出两条规则：
- 长期密钥只留在控制面。事件监听器、内部应用和沙箱命令通过代理或短期窄权限令牌调用，Agent 和脚本不直接接触刷新令牌。
- 上游系统保持权威。ERP 或 Shopify 同步来的订单和库存进入只读镜像列；内部备注单独存放，避免本地编辑覆盖外部事实。
当 Agent 想修改线上价格或发起付款时，控制面暂停执行，向获授权负责人展示账号、SKU 和金额，收到人工批准及上游回执后才更新本地镜像。这个流程把“建议写入”和“确认事实”分成两步。
5. 组织记忆：本体骨架加上可追溯经验
一份不断变长的 MEMORY.md 或普通向量 RAG 很难承载企业经验。单纯按文本块切分会丢失实体、时间、口径和权限；把受限报告合进公共摘要又会产生侧信道泄露。
文章提出两部分结合的记忆系统：
| 部分 | 作用 |
|---|---|
| 受类型约束的实体骨架 | 围绕供应商、SKU、店铺、订单和项目建立可校验的关联边 |
| 类睡眠的后台整合 | 从对话流和业务事件流中提炼带日期的事实、阶段摘要和隐性规律，归档被新证据推翻的旧判断 |
未经证实的说法要保留发言人和限定词，例如“某人在周会上推测”，不能因为同一个猜测被重复提及，就凭空升级为事实。每条记忆还应保留指向源消息、页面或事件的硬链接；召回前检查提问者、Agent 和房间受众是否有权访问所有源材料。
撤回源报告后，引用它的派生记忆也应在下一次读取时隐藏。公开摘要和受限结论要分开存放，避免一条机密判断污染整个供应商页面的可见性。
Skill 和 AGENTS.md 不应当是普通共享文件
在单用户 Claude Code 中，Skill 和 AGENTS.md 放在项目文件里很自然；迁移到多人工作空间后，它们既定义 Agent 的能力，也影响运行时安全边界。把它们当普通文件按用户权限过滤，可能导致同一会话中途能力突然缩水；允许所有人自由改名和编辑，又会破坏固定加载路径。
文章的方案是把记忆、Skill、规则和连接器放入独立治理表。Agent 可以在工作空间起草候选 Skill 或规则差异，但只有经过授权的人审批后才生效。协作空间负责提出变更，治理空间负责发布变更。
6. 控制面与执行沙箱分离
文章将有状态控制面与按需 Linux 沙箱拆开：
- 控制面保存持久状态、权限图、凭据、会话路由和提交入口。
- 沙箱运行 Bash、Python、DuckDB、无头浏览器和编程 CLI，默认没有长期密钥，也不能直接写数据库。
- 轻量查询和表格更新在控制面内毫秒级完成；只有长脚本、浏览器和仓库级代码任务才唤醒沙箱。
- 沙箱崩溃不会拖垮控制面，控制面滚动发布也不应中断正在运行的长命令。
文章进一步提到用 Elixir/OTP 的有状态 Actor 处理跨天存活、被异步事件反复唤醒的会话。会话空闲时状态落盘到 Postgres，消息、A2A 回复或 Webhook 到达时再唤醒对应进程，避免用无状态 HTTP 胶水硬拼分布式锁和任务队列。
7. FUSE 文件系统：让标准工具读到受控业务数据
如果业务数据只存在控制面，沙箱里的 ripgrep、DuckDB 和 Claude Code 仍然需要一种本地文件视图。文章提出按权限挂载的 FUSE 虚拟文件系统：
- 文档和附件呈现为可编辑 Markdown 或普通文件。
- 结构化数据表以只读快照挂载，适合 DuckDB、pandas 和命令行工具扫描。
- 写回数据必须经过带类型、唯一键和版本校验的导入或补丁命令。
- 记忆、Skill 和规则目录只读挂载，避免沙箱绕过出处核验或篡改线上规则。
- 不同权限范围的并发会话隔离挂载命名空间、工作目录、恢复目录和
/tmp。
慢脚本先在本地完成写入，再由服务端按共同祖先版本做类似 Git 的三方合并。不同段落的修改可以自动合入；同一段发生冲突时，保留恢复副本并交给 Agent 或人调解，而不是用网络锁把浏览器保存卡住。
8. 为什么这不只是“办公软件加聊天框”
文章把真正的 Agent OS 原语总结为：组合唯一键、字段版本、权限委托、隔离 A2A、可追溯记忆、有状态 Actor、按权限的 FUSE 挂载和三方合并。它们共同解决的是组织级问题：
共享状态 → 可并发更新
身份与权限 → 能协作但不越权
记忆与规则 → 能积累且可撤回
控制面与沙箱 → 能执行且隔离故障
标准文件视图 → 能复用现有工具链
更强的模型可以提高 Slow Path 的规划和归纳质量，却不会自动解决两个 CSV 分叉、权限交集、凭据隔离或冲突合并。模型能力和组织系统能力是两条不同的轴。
设计落地时应先验证什么
原文是 Ankole 的工程实践与架构主张，并没有在这条 X Article 中给出完整开源代码、公开部署规模或独立验收报告。因此，实际评估类似 Agent OS 时，可以先做小范围的可验证实验：
- 用两种角色和一张共享表验证字段级并发写入，确认过期版本不会静默覆盖。
- 用一个只读法务 Agent 验证 A2A：它能读取自己的档案，但不能把原始档案发给低权限调用者。
- 撤回一份源文档，检查所有派生摘要是否在下一次召回时隐藏。
- 让沙箱运行一个长任务，同时重启控制面，确认状态能恢复且长期凭据没有进入沙箱。
- 让两个沙箱修改同一文档的不同段落，再制造同段冲突，检查三方合并和恢复目录。
这些实验比“群里能不能叫到机器人”更能判断一个系统是否真的具备 Agent OS 的基础。权限日志、审批回执、错误恢复和数据血缘都应该是验收输出的一部分。
结语
Ankole 文章把团队 Agent 的难题重新放回操作系统和分布式系统的语境：业务对象要持久，权限要由内核强制，记忆要有出处和时间，计算要能隔离和恢复，标准工具链要有受控的本地视图。聊天只是一个入口，不应成为所有状态的最终容器。
对于个人使用者，这套设计的启发是给 Agent 划清工作区、凭据、记忆和执行环境；对于团队，则要先把权限、数据权威和审批边界定义清楚，再谈接入更多模型和工具。真正的 Agent OS 不是把更多 MCP 塞进群聊，而是让组织的隐性知识能够在权限可控的前提下被记录、复用、分支和合并。