# The road to Seahaven:如何不用权限提示运行 Agent Harness ## 一、为什么"权限提示"是个真问题 用 LLM 写代码、用 Agent 处理文件,每个 Agent Harness(执行底座)默认会在每次工具调用前弹出权限提示:"Allow agent to read /home/user/private/secrets.txt?" 这种设计有两个根本问题: **

# The road to Seahaven:如何不用权限提示运行 Agent Harness ## 一、为什么"权限提示"是个真问题 用 LLM 写代码、用 Agent 处理文件,每个 Agent Harness(执行底座)默认会在每次工具调用前弹出权限提示:"Allow agent to read /home/user/private/secrets.txt?" 这种设计有两个根本问题: **问题一:工作流被频繁打断** Agent 一跑就是几十上百次工具调用,每次都弹一个"Allow?"。用户本来想"放着让它跑,一会儿回来",结果回来发现它停留在第 3 步等你批准。**任何超过 10 分钟的 Agent 任务都会被权限提示拖垮节奏**。 **问题二:权限提示本身不安全。它要求的是认知负荷 + 自律**: - 用户大概率会无脑点 "Allow",因为已经烦了 - 用户不会真去判断"这个文件是不是该让 Agent 读" - LLM-based 判读(让 LLM 决定要不要弹提示)是补丁叠补丁 作者在 2026 年 8 月 15 日的工程博客 **"The road to Seahaven"** 里给出了一个清爽的替代方案:**用 sandbox 控制 agent 的"现实",而不是用提示控制 agent 的"行为"**。 ## 二、Pi coding agent 的设计哲学:把安全推到 harness 外 Pi 是一个 coding agent(类似 Claude Code 的本地工具),它的设计哲学跟主流截然不同: > "Pi has no permission prompts at all. It delegates the solution to outside of itself — such as to sandboxes, containers, and virtual machines." 中文:**Pi 没有任何权限提示。它把问题的解决推到自身之外——比如 sandbox、容器、虚拟机**。 这一层之上,我们能控制 agent harness 的"现实"——我们可以刻意决定 harness 能看到哪些文件。**如果 agent 能看到一个文件,那是因为我们允许它看到**。一旦做到这个,权限提示就冗余了。 这种思路把"安全"从**应用层**(agent 弹窗问)推到**系统层**(sandbox 隔离),这才是根本解。 ## 三、bubblewrap 的力量:不是 VM,不是容器,只是个 shim 作者用了 Linux 的 bubblewrap(用户态 namespace 包装工具)做 Pi 的 harness: - **不是启动一个虚拟机**——启动开销可忽略 - **不是启动一个容器**——不需要镜像构建 - **只是个 shell 脚本级别的 shim**,用 Linux namespace 把进程视野限制住 具体效果: - 当前工作目录挂载到 `/work` - 临时空 host 目录挂载到 `/tmp` - 系统目录按需挂载 - **home 目录其他部分完全不可见** 启动一个 Pi coding agent 现在是这样: ```bash cd ~/Repos/nixpkgs pi-here ``` Pi 看到 Nixpkgs repo 在 `/work`,可以自由读写,但**看不到用户 home 目录下的任何私人文件**。这就是把"安全"从"用户决策"变成"系统约束"的根本差异。 ## 四、Seahaven:从单目录到多文件 workshop `pi-here` 解决了单目录场景。但作者很快遇到下一个需求:**修改简历,要基于多份原始材料**——职业故事、读书笔记、其他文档。 最初方案是手工复制到"base camp"目录再用 `pi-here`,问题:**复制过去后,改完忘记复制回来,所有更新丢失**。 这个问题引出了 **Seahaven** 的设计思路:**每个"工作场景"自带配置文件,声明要拉入哪些外部文件**: - 不集中管理配置(在 `~/.config/...` 里写全局 config 是反模式) - **跟随文件系统自然组织**——resume workshop 在 `~/documents/2026/career`,配置文件就在那里 - 配置格式简单:每行 `ro ` 或 `rw `,声明这个 workshop 需要哪些只读 / 读写文件 这套设计回答了三个问题: - **我用什么文件**:在 Seahaven 配置里显式列出 - **哪些文件可写**:按 `ro` / `rw` 区分 - **哪些文件隔离**:不在配置里的文件,sandbox 里看不见 ## 五、Seahaven 的核心创新:让"安全"成为文件系统约定 Seahaven 真正改变的是**人机协作的安全模型**: **传统模式**: - 用户:信任 harness(harness 不会乱读) - Harness:信任用户(用户会批准每个动作) - 信任链两端都依赖"对方做对事" **Seahaven 模式**: - Sandbox:不依赖 trust,只暴露配置里声明的文件 - Harness:看不到未声明文件,无机会犯错 - 信任链缩短成**"配置文件 = 约定"** 这套模型对开发体验的实际影响: - Agent 不再弹窗,工作流不被中断 - Agent 看不到的东西它也不会"误读",保护是结构性的 - 配置随项目走,新人加入团队看到 Seahaven 配置就知道"这个项目的 Agent 工作范围" ## 六、为什么这条路比 Claude Code / Cursor 更"干净" 主流 coding agent(Claude Code、Cursor、Aider)都还在走"权限提示 + LLM 判读"的路线,原因是: - 跨平台:必须支持 Windows、macOS——这些平台没有 bubblewrap 那种轻量 namespace 工具 - 降低门槛:让不会 Linux namespace 的开发者也能用 - 商业化:权限提示能做成"安全卖点"卖给企业 IT 但 Seahaven 的做法揭示了一个更深的事实: **权限提示是用户教育成本转嫁**——把"你应该知道哪些文件敏感"的责任推给用户,但用户没有这个能力,于是变成"无脑 Allow"。 **Sandbox 是结构性保护**——不需要用户做决策,系统层就保证 agent 看不到未授权文件。 Linux 原生 namespace 工具(bubblewrap、firejail)免费、零启动开销、零依赖。让 sandbox 路线"不干净"的从来不是技术,是跨平台兼容。 ## 七、个人 Agent Harness 的另一个教训:别把 memory 当检索问题 2026 年 5 月 30 日 HN 上的一篇实战复盘 **"I spent a year building agent memory on knowledge graphs. Here are my 5 mistakes"** 给出了完全不同的教训,但跟 Seahaven 是同一个主题:**Harness 自演进**。 作者花了一年时间在 MongoDB 知识图谱上构建 Agent 的统一记忆层,失败了的 5 个教训: **教训一:框架优先是死路** 直接用 LangGraph、CrewAI 等现成框架,结果自己的需求一深入(自定义 ontology 约束、不可变观察日志、复合 ID、多跳遍历),就跟框架打架。 > "Own the memory and the harness yourself because frameworks encode assumptions your system rarely matches." 翻译:**自己拥有 memory 和 harness,因为框架内嵌的假设很少能匹配你的实际系统**。 **教训二:ontology 设计不能"先完美后落地"** 第一次就想设计完美 ontology,**项目冻了几个月**。教训是:**ontology 设计是数据探索循环,不是设计文档**。先从 POLE+O(Person/Object/Location/Event/Organization)开始,只在出现冲突时扩展。比如你会发现"Claude Code" 不该是 Person 应该是 Object。 **教训三:把 memory 当数据建模问题,不是检索问题** 文件搜索在 memory 变大时会让 context window 爆掉。即使是 semantic search over history,也没法穿越"人/主题/对象/位置/偏好"之间的关系。 > "The fix was to stop treating memory as a retrieval problem and treat it as a data-modeling problem." **教训四(及之后)**:具体细节文中展开,但核心一致——**Agent Harness 的每一个组件(memory、sandbox、tool registry、permission model)都不应该由外部框架"代答",应该自己拥有**。 ## 八、Seahaven + memory 反思的共同主题 这两篇文章看似无关,实则指向同一个判断: **Agent Harness 不是产品,是基础设施**。 - 产品:可以买现成的(Claude Code、Cursor) - 基础设施:必须自己拥有,因为它是"我的 agent 怎么跑"的核心约定 Seahaven 论证了 sandbox 应该自己搭——5 mistakes 论证了 memory 应该自己建。两个作者都在说同一句话:**别用现成的 harness,因为没人比你自己更知道你的 agent 应该看到什么、记住什么**。 ## 九、对企业的现实启示 **短期(立刻)**: - 如果你在 Linux 跑 coding agent,**强烈推荐 Seahaven 思路**——bubblewrap + per-project 配置,几乎零成本就能消除"权限提示疲劳 + 文件误读"两个问题 - **不要再依赖"agent 自己判断要不要读敏感文件"——这种信任模型在规模化时一定崩** - 团队层面建立"每个项目的 agent workspace 配置"约定,跟 `.gitignore` / `Dockerfile` 一样是工程纪律 **中期(3-6 个月)**: - 如果你的产品/团队跨 Windows / macOS / Linux,**主动推动 bubblewrap 类轻量 sandbox 的跨平台实现**——这是企业 Agent Harness 的真缺口 - memory 层不要"先图谱后实战",从 POLE+O 这种最小 ontology 起步,按数据冲突迭代 - 把 Seahaven 思路扩展到非 coding agent(数据处理、文档生成、运维自动化)——同样适用 **长期(1 年+)**: - 企业 Agent 治理的核心竞争力从"选哪个 Agent 产品"转向"我们的 Agent Harness 长什么样" - Sandbox-as-config会成为主流——配置即边界,边界即安全 - 跨平台 sandbox(bubblewrap for Windows/macOS)会变成新基础设施赛道,跟容器编排之于 Kubernetes 同一逻辑 ## 十、回到题目:如何不用权限提示运行 Agent Harness 答案不在 agent 本身,在 **sandbox**。 - 不要让 Agent 决定要不要读文件——这是信任问题,Agent 不可信 - 不要让用户决定要不要允许——这是认知负荷问题,用户不可靠 - 让**文件系统 + Linux namespace** 决定 Agent 看到什么——这是结构问题,可验证、可工程化 Seahaven 这条路把 Agent Harness 从"产品思维"(做更多功能)转向"基础设施思维"(做更稳的约束)。这条路目前只有小众玩家在走,但**它的工程正确性会在规模化时被验证**。 如果你正在用 Claude Code / Cursor 并被权限提示困扰,Seahaven 给了你一个 Linux 上立即可用的解药。如果你不在 Linux 上,这套思路仍然值得借鉴——它指出了 Agent Harness 的下一个工程方向:**配置即边界,sandbox 即安全**。 个人 Agent Harness 的真正护城河不是 Agent 多聪明,是 Harness 多干净。Seahaven 是个干净的 Harness。