简要结论
理解 Agent 能看到什么、哪些操作需要批准，以及如何建立安全试用边界。
工作区决定文件能力的主要边界；会话记录一次任务的事件历史；权限策略决定哪些副作用需要人工确认。这三者共同定义了 Agent 的实际操作面。
工作区不是装饰性设置
选择工作区后，Agent 可能读取文件、修改内容、运行命令或调用插件。第一次试用时：
- 使用专门的测试目录；
- 不放
.env、私钥、生产数据或密码导出文件； - 提交或备份原始状态；
- 先要求只读分析，再逐步允许修改。
Session Log 为什么重要
官方架构把 Session Log 作为模型上下文的事实来源。用户消息、模型输出、工具调用和工具结果都以事件形式记录，恢复、Fork、回放和 UI 展示由此派生。
这意味着“模型看到的内容”原则上应当能够从日志重建。排查问题时，比起只看最终回答，更应该查看调用链和工具结果。
官方生命周期把两类事实分开：需要回放的用户消息、模型输出和工具结果进入 session/* 事件；只用于当前运行协调的状态进入 agent/*。这能帮助你判断“重启后应该恢复什么”。
权限预设包含两个旋钮
权限预设同时组合：
- Sandbox mode：进程在文件系统上实际能做什么；
- Approval policy：什么时候需要向用户请求批准。
二者不能互相替代。即使提示词写着“不要修改”，没有沙箱时仍只是软约束；即使采用只读沙箱，审批策略仍决定某些调用是否需要人工确认。官方默认预设包括 workspace-write 与 danger-full-access，后者应只在你理解全部影响时使用。
如何处理审批
审批不是“不断点同意”的流程，而是检查操作是否符合原始目标：
- 命令将读取或修改哪些文件？
- 是否会连接网络或上传数据？
- 是否会安装第三方代码？
- 是否可能删除、覆盖或移动大量文件？
- 是否有更小权限的替代方案？
不理解的命令不要批准。可以要求 Agent 先解释影响、缩小范围，或改成只读检查。
一个安全的练习
在测试仓库里让 Agent：
读取 README 和 package.json，总结项目；列出你下一步想执行的命令，但先不要运行。确认计划后，再逐条允许只读命令。这个练习能帮助你认识 Harness 的权限交互，而不需要立即修改项目。
第二阶段：有限写入
复制一个测试文件，然后要求：
只修改 sandbox-demo/README.md，在末尾增加一行“harness test”。
不要运行安装命令，不要访问网络，不要修改其他文件。
完成后给出 diff，并列出实际调用的工具。验收时同时检查：
- diff 是否只有一个文件；
- 会话日志是否出现了对应工具调用和结果；
- 是否发生未声明的命令或网络操作；
- 拒绝一次审批后，Agent 是否能调整方案而非绕过限制。
最后删除测试目录或恢复该文件。生产仓库开始前，先提交或备份干净基线。