Harness 工作区机制详解，AI 能碰哪些文件怎么限定

工作区AI 操作的第一道边界第一次打开 DeepSeek Harness 的 Web UI你会在界面上方看到一个显眼的「选择工作区」按钮。这个看似简单的入口实际上决定了后续 AI 能碰哪些文件、不能碰哪些文件。对于同时维护多个项目、或者担心 AI 误删误改关键配置的开发者来说理解这套机制至关重要。Harness 的工作区本质上是一个文件系统边界声明。当你选定某个目录作为工作区后AI 的所有文件读写、Shell 命令执行都被限制在这个目录范围内。UI 输入框变灰十有八九是因为还没选工作区——这不是 bug而是框架刻意设计的保护性拦截。文件系统权限的边界在哪里Harness 不会因为你选了/home/alice/projects/my-app就自动获得整个系统的访问自由。它的权限模型可以概括为**「目录即牢笼」**读权限AI 可以遍历工作区内的所有文件包括子目录递归读取写权限仅限于工作区路径下的文件创建、修改与删除Shell 执行工作目录被固定为当前工作区根路径无法通过cd ..逃逸这里有个细节值得注意Harness 对符号链接的处理策略。如果工作区内存在指向外部目录的软链接Harness 会跟随链接读取目标内容但写入操作会被拦截。这意味着你可以在工作区里放几个指向公共依赖库的 symlink 让 AI 理解项目结构而不必担心它把改动写到其他项目里去。实际使用中建议把符号链接指向只读位置或者干脆用硬链接替代可写资源。虽然 Harness 的跟随策略已经做了安全隔离但减少不必要的边界穿透总能让心里更踏实。.gitignore 与 AI 的「视觉盲区」项目里的.gitignore文件对 Harness 同样生效但作用方式可能和你想的不太一样。Harness 在读取文件列表时会尊重.gitignore规则被忽略的文件不会出现在 AI 的上下文里。这带来一个直接好处构建产物、依赖缓存、临时文件这些噪音被自动过滤AI 能更专注于核心源码。但反过来看这也意味着 AI 对.gitignore覆盖的内容是不可见的——如果你把某个配置文件加了忽略规则然后问 AI「这个配置值怎么填」它给不出答案。更隐蔽的坑在于嵌套的.gitignore。Harness 采用与 Git 一致的规则解析方式子目录下的忽略规则会正确生效。有些开发者习惯把敏感配置统一放在项目根目录的.env文件里再用.gitignore忽略这种做法在 Harness 里同样会让 AI 看不到这些变量。需要 AI 协助配置管理时要么临时调整忽略规则要么把需要 AI 参考的配置抽离到不被忽略的文件中。敏感文件的自动保护策略.env文件里躺着数据库密码、API 密钥、私钥证书——这些东西当然不能让 AI 随便读取更别提交给云端模型。Harness 在这方面做了分层防护第一层是路径黑名单。以.env为典型代表Harness 内置了一组敏感文件模式匹配规则涵盖常见的密钥存储文件、证书文件、SSH 私钥等。匹配到的文件会被标记为受限AI 的读取请求会被拒绝相关路径在日志中也会脱敏显示。第二层是内容扫描。对于不在黑名单中的文件Harness 会执行启发式检测。如果文件内容包含高熵字符串疑似随机生成的密钥、或符合KEYsecret_value这类键值模式同样会触发保护机制。这层防护的误报率控制得不错正常的业务代码里的普通常量不会被误伤。第三层是操作审计。Trajectory 日志会记录 AI 对敏感文件的每一次访问尝试无论成功还是失败。这意味着即使某次误操作突破了前两层防护你也能在回放中定位到具体时间点、具体请求。需要强调的是这些保护策略默认启用且不可关闭。如果你确实需要让 AI 读取某个被误判的文件目前的变通方案是修改文件名或调整内容格式而非禁用保护——这体现了 Harness 在安全性上的保守倾向。多工作区切换与上下文重置Harness 支持在多个工作区之间快速切换但每次切换都伴随着完整的上下文重置。这包括当前会话的文件系统缓存被清空已加载的项目级知识如代码索引需要重新构建之前的对话历史虽然保留在 Trajectory 中但不再作为当前上下文的一部分这种设计的出发点是隔离性。假设你先在project-a里让 AI 分析了业务逻辑再切换到project-b处理另一个需求如果不做上下文重置AI 可能会把 project-a 的接口设计套用到 project-b 上造成危险的交叉污染。代价则是切换工作区后的「冷启动」延迟。对于大型项目重新索引文件可能需要几十秒。我的习惯是在开始一个长任务前先确认好工作区不再变动避免中途切换打断节奏。Docker 沙箱工作区的「加固版」上述机制运行在 Harness 的主进程环境中属于进程级隔离。如果你需要更强的安全保证可以启用 Docker 沙箱模式。在 Docker 模式下每个工作区被映射到一个独立的容器实例中。AI 的文件操作实际发生在容器内部即使发生极端情况比如 AI 执行了rm -rf /破坏范围也仅限于容器层不会触及宿主机。容器销毁后所有变更一并消失——除非你通过卷挂载做了持久化配置。与工作区原生模式相比Docker 沙箱的差异主要体现在维度原生工作区Docker 沙箱隔离级别进程级容器级启动速度即时数秒级需拉取/启动镜像文件持久化直接写入宿主目录需显式挂载卷网络访问受限可控可通过容器网络策略额外限制资源限制依赖宿主 cgroup可配置 CPU/内存上限对于个人开发机上的日常调试原生工作区通常够用涉及不可信代码执行、或需要严格资源管控的 CI 场景Docker 沙箱更值得考虑。与 Cursor 的 workspace 机制对比同为 AI 编程工具Cursor 的 workspace 机制常被拿来与 Harness 比较。两者的核心差异在于控制粒度Cursor 的 workspace 更偏向「项目配置容器」主要管理的是索引范围、AI 规则文件、自定义指令等元数据。它的文件权限边界相对宽松AI 理论上可以访问整个项目树依赖的是 IDE 层的操作拦截而非系统级限制。Harness 则把 workspace 做成了安全沙箱的入口。从选择工作区的那一刻起文件系统边界、敏感文件保护、上下文生命周期都被严格管控。这种设计让 Harness 更适合多项目并行、或需要明确审计 AI 行为的场景而 Cursor 的流畅体验则更受单项目深度开发者的青睐。另一个值得关注的点是多工作区并发。Cursor 目前不支持同时打开多个 workspace切换意味着重启窗口。Harness 的架构则允许并行运行多个工作区实例每个实例有独立的 Trajectory 日志和上下文状态——这对于需要对比不同项目实现、或同时处理前后端分离项目的开发者来说是更灵活的选择。实际配置建议基于上面的机制解析这里给出几条可直接落地的配置策略工作区组织为每个项目创建独立目录避免多个项目混在同一个大文件夹下。Harness 的工作区选择是目录粒度的合理的目录结构能让权限边界更清晰。敏感文件管理把.env等密钥文件放在项目根目录并加入.gitignore利用 Harness 的自动保护机制。如果某些配置需要 AI 参考但不希望暴露真实值可以维护一份.env.example作为脱敏模板。符号链接使用用 symlink 引入外部只读依赖如共享的 protobuf 定义避免复制带来的版本同步问题。确保链接目标不在工作区外提供写权限。Docker 沙箱启用在harness.json或启动参数中指定沙箱模式配合卷挂载实现「容器内计算、宿主机持久化」的混合方案。首次配置时留意 UID/GID 映射避免容器内写入的文件在宿主机无法访问。Trajectory 定期审查利用轨迹回放功能抽查 AI 对敏感文件的访问记录。这不仅是安全审计也能帮你发现配置疏漏——比如某个不该被 AI 看到的文件为何出现在了读取日志中。Harness 的工作区机制没有追求极致的简洁而是在安全与便利之间做了务实的平衡。理解这些边界规则后你可以更放心地把代码交给 AI 处理同时守住那些不该被触碰的底线。