OpenShell 这个名字第一次听到的人大概率会猜错方向。有人以为是某个新出的终端工具有人觉得是操作系统里的一个组件还有人直接把它和容器、沙箱联系起来。我最初接触它的时候也走了弯路翻了半天文档才发现它真正解决的问题比这些猜测都要具体给 AI 智能体Agent提供一个可编程、可审计、可约束的执行外壳。换句话说当你的大模型不再只是聊天而是要真正去调用工具、读写文件、执行命令、访问网络的时候OpenShell 就是那个夹在模型和真实世界之间的安全驾驶舱。这篇内容适合三类人看一是正在做 Agent 应用、被模型乱调工具折磨过的开发者二是对 AI 执行安全、权限隔离感兴趣的技术负责人三是想搞清楚 OpenShell 到底值不值得引入的技术选型者。我会从它要解决的核心痛点讲起拆解它的策略模型、执行链路、权限边界再给出一套可以照着跑的落地步骤最后把我踩过的坑和实测经验摊开讲。全文基于 OpenShell 这类智能体外壳/执行沙箱的通用设计思路展开具体 API 名称以你实际使用的版本为准但底层逻辑是相通的。1. 为什么裸奔的 Agent 一定会出事1.1 从能聊天到能动手的那道坎大模型本身是个纯文本进、纯文本出的东西。它不会真的去删你的文件也不会真的去发一封邮件——除非你给了它工具。所谓 Agent本质就是模型 工具调用循环模型输出一个结构化的调用意图你的程序去执行再把结果喂回模型如此往复。问题就出在你的程序去执行这一步。绝大多数人第一版 Agent 是这么写的模型说要执行什么命令就直接subprocess.run()跑模型说要读哪个文件就直接open()读。这在 demo 阶段爽得飞起一旦上线就是灾难。我见过最离谱的一个案例是模型在调试过程中自己拼出了一条递归删除的命令幸好当时跑在测试机上否则整个项目目录就没了。OpenShell 这类工具存在的根本理由就是把模型想做什么和系统实际执行什么这两件事彻底分开。模型永远只能申请真正执行与否、以什么权限执行、执行结果给不给它看全部由外壳这一层说了算。1.2 三类典型事故暴露的是同一个缺口我把实际遇到过和听说过的 Agent 事故归成三类你会发现它们指向的是同一个设计缺陷。第一类是越权访问。模型为了完成帮我总结一下项目这个任务顺手去读了~/.ssh或者环境变量里的密钥文件。它没有恶意它只是觉得这些文件可能相关。但结果就是敏感信息进了模型的上下文甚至可能被写进日志。第二类是不可逆操作。删除、覆盖、格式化、发送——这类操作一旦执行就没有回头路。模型对危险的判断力和人类完全不在一个量级它可能因为一个措辞模糊的指令就触发破坏性动作。第三类是资源失控。模型陷入循环反复调用同一个工具或者某个命令挂死不返回把整个 Agent 进程拖垮。没有超时、没有配额、没有熔断一个 bug 就能烧掉你一整晚的算力。这三类问题的共同点是它们都不是模型能力的问题而是约束的问题。你不可能靠提示词让模型永远不犯错你只能在外壳层面把犯错的代价控制住。这就是 OpenShell 的核心价值主张。1.3 外壳不是加个 if 判断那么简单很多人第一反应是那我写个函数判断一下命令里有没有rm -rf不就行了这种字符串黑名单的思路我劝你趁早放弃。原因很简单绕过方式太多了。rm -r -f、rm --recursive --force、用变量拼接、用 base64 解码后再执行、调用一个自己写的脚本间接删除……你永远列不全黑名单。安全领域有个基本原则叫默认拒绝deny by default黑名单是默认允许方向就反了。OpenShell 采用的是白名单 策略引擎的思路默认什么都不让做你显式声明允许哪些能力、在什么条件下允许、允许到什么程度。这个思路的转变是从堵漏洞到划边界是质的区别。理解了这一点你才能理解它后面所有的设计。2. OpenShell 的策略模型能力、约束、审计三件套2.1 能力Capability把权限拆成最小颗粒OpenShell 的第一个核心概念是能力。它不给你一个笼统的执行权限而是把 Agent 能做的事拆成一个个独立的能力单元。常见的能力维度包括文件系统能力读、写、创建、删除而且要细化到路径级别。比如允许读/workspace/data但不允许碰/workspace/config。命令执行能力允许执行哪些可执行文件是否允许带参数是否允许管道和重定向。网络能力允许访问哪些域名或地址段允许哪些协议和端口。环境能力能读取哪些环境变量能访问哪些系统资源。这种拆法的好处是你可以精确地表达这个 Agent 只需要读数据、算结果、写报告这样的意图而不必给它一整套系统权限。最小权限原则Principle of Least Privilege在这里不是口号而是可以直接配置的东西。我个人的经验是能力配置要从零开始加而不是从全量开始减。你先假设 Agent 什么都不能做然后根据它实际完成的任务一项一项往上加。每加一项都问自己这项能力如果被滥用最坏结果是什么能接受就加不能接受就换方案。2.2 约束Constraint给能力加上条件和上限光有能力还不够你还得控制用多少什么时候能用。这就是约束层的作用。OpenShell 里常见的约束类型有这么几种数量约束比如最多执行 50 次命令、最多写 10 个文件。防止模型陷入循环或者被诱导做批量操作。时间约束单次命令最长执行 30 秒整个会话最长 10 分钟。超时直接终止避免挂死。空间约束写入的总字节数上限、单个文件大小上限。防止磁盘被写爆。条件约束某些能力只在特定条件下开放。比如只有在工作目录内才允许写文件或者只有在用户显式确认后才允许执行删除。约束的价值在于它把绝对安全这个做不到的目标换成了风险可控这个能做到的目标。你没法保证 Agent 永远不犯错但你可以保证它犯的错在可承受范围内。2.3 审计Audit每一次执行都留下痕迹第三个支柱是审计。OpenShell 会把每一次能力调用完整记录下来谁申请的、申请了什么、策略怎么判定的、执行结果是什么、耗时多久。这份日志有两个用途。一是事后追溯。当 Agent 做出了意料之外的行为你能精确还原它当时想做什么被允许做什么实际做了什么。没有审计日志排查 Agent 问题基本靠猜。二是策略调优。你翻日志会发现很多你当初以为需要的能力实际上 Agent 从来没用过而有些你没预料到的调用频繁出现。根据真实日志去收紧或放宽策略比拍脑袋配置靠谱得多。提示审计日志本身也可能包含敏感信息比如命令参数里的路径、文件名。日志的存储和访问权限要单独管理别让审计系统变成新的泄露点。3. 一次工具调用在外壳里到底经历了什么3.1 从模型输出到实际执行的完整链路理解执行链路是排查问题的前提。我把 OpenShell 处理一次工具调用的过程拆成六个阶段你可以对照自己的实现看看卡在哪一环。第一阶段意图解析。模型输出的是一段结构化文本通常是 JSON描述它想调用哪个工具、传什么参数。外壳首先要做的是解析这段文本校验格式是否合法。格式都不对的调用直接拒绝不要试图猜模型的意思。第二阶段能力映射。把工具调用映射到具体的能力项。比如调用 shell 工具执行ls映射到命令执行能力读取 report.txt映射到文件读取能力。这一步决定了后面用哪条策略去判定。第三阶段策略判定。拿能力项和参数去匹配策略规则。命中允许规则就放行命中拒绝规则就拦截没有匹配任何规则则按默认策略处理通常是拒绝。这一步是整个外壳的大脑。第四阶段执行前准备。放行之后还要做执行环境的准备切换到受限的工作目录、设置资源限制、准备超时控制、注入必要的环境变量。这一步容易被忽略但它决定了执行是否真的被关在笼子里。第五阶段实际执行。在受控环境下真正跑起来。执行过程中要持续监控资源占用和超时一旦越界立即终止。第六阶段结果处理与回传。把执行结果标准输出、标准错误、退出码做必要的截断和脱敏再回传给模型。注意回传的内容也要过一遍策略别让执行结果里的敏感信息直接进模型上下文。3.2 为什么执行前准备是最容易被做错的一环我见过不少自己实现的简易外壳策略判定做得挺认真但执行前准备几乎没做。结果就是策略上写着只能访问工作目录实际执行时进程的工作目录根本没切模型一个相对路径就跳出去了。这里的关键认知是策略判定是逻辑层的约束执行环境是物理层的约束两者必须同时到位。逻辑层告诉你应该只允许访问 A 目录物理层要确保即使逻辑层被绕过进程也真的访问不到 B 目录。前者靠代码后者靠操作系统提供的隔离机制比如工作目录切换、资源限制、权限降级。举个具体的例子。假设你允许 Agent 执行python命令但只允许它运行工作目录下的脚本。逻辑层你可以检查命令参数里的脚本路径。但如果 Agent 执行的是python -c import os; os.system(...)参数里根本没有脚本路径你的检查就失效了。这时候物理层的隔离——比如把进程关在一个只能看到工作目录的环境里——才是真正的兜底。3.3 结果回传的截断与脱敏别省这一步模型上下文是有限的执行结果动辄几万行全塞回去既浪费 token 又可能触发长度限制。所以结果回传前必须截断。但截断有个坑你不能简单地从中间截因为命令的关键信息比如报错往往在末尾。我的做法是头尾保留 中间省略保留前 N 行和后 M 行中间用省略标记代替。对于标准错误优先保留因为报错信息更重要。对于超长单行输出还要做行内截断否则一行几万个字符照样撑爆上下文。脱敏则是另一层。执行结果里可能包含路径、用户名、内部地址等信息。如果这些不该进模型上下文就要在回传前替换掉。这一步很多人觉得没必要直到某次审计发现模型上下文里躺着一堆内部路径才后悔。4. 把 OpenShell 跑起来从零到可用的落地步骤4.1 环境准备与最小可用配置假设你已经拿到了 OpenShell 的代码或包第一步不是急着写策略而是先跑通一个什么都不允许的最小配置。这一步的目的是验证外壳本身能正常工作把环境问题和策略问题分开排查。最小配置大概长这样以伪配置为例具体字段名以你的版本为准shell: default_policy: deny # 默认拒绝这是安全基线 audit: enabled: true log_path: ./audit.log limits: max_commands: 20 command_timeout: 30 max_output_bytes: 1048576 capabilities: [] # 先什么都不给跑起来之后你让 Agent 随便调一个工具应该看到它被拒绝并且审计日志里记录了这次拒绝。如果这一步就失败了说明外壳没接对先别往下走。注意default_policy: deny是必须的。我见过有人图省事设成allow想着先跑通再收紧结果这个临时配置一直留到了生产环境。4.2 按任务反推能力清单环境跑通后开始加能力。方法不是猜 Agent 需要什么而是让它先失败看它申请什么。具体操作是保持默认拒绝让 Agent 去完成一个真实任务它会因为权限不足而失败失败信息里会告诉你它想调用什么能力。你据此逐条添加。举个例子任务是读取 data 目录下的 CSV统计行数把结果写到 report.txt。Agent 会依次申请读data/*.csv、执行统计命令或者它自己写代码算、写report.txt。你对应的能力配置就是capabilities: - type: file_read paths: [./data/*.csv] - type: file_write paths: [./report.txt] - type: command_exec executables: [python3] allow_args: true注意这里executables只放行了python3没放行rm、curl这些。Agent 如果真想删文件或联网会被直接拦下。这就是白名单的威力。4.3 用真实流量压一遍策略配置写完不代表完事。你得用一批真实或接近真实的请求去压一遍看策略会不会误伤正常操作或者漏放危险操作。我一般会准备三类测试用例用例类型目的示例正常用例验证合法操作不被误拦读指定 CSV、写指定报告边界用例验证策略边界是否精确读同目录下未授权的文件、写超出范围的路径恶意用例验证危险操作被拦截尝试执行删除命令、尝试访问敏感路径三类都跑通策略才算基本可用。这里有个经验边界用例最容易暴露配置漏洞。比如你配了./data/*.csv那./data/../config/secret.txt算不算命中取决于你的路径规范化做得好不好。这类问题不测是发现不了的。4.4 上线前的最后三道检查正式接入生产前我会强制过三道检查。第一道默认策略确认。再确认一遍default_policy是deny且没有任何临时放行的残留配置。第二道审计开关确认。审计必须是开着的且日志路径可写、有轮转策略否则日志会把磁盘写满。第三道熔断确认。确认数量、时间、空间三类约束都配了合理值且触发后的行为是终止并告警而不是静默忽略。这三道检查看着简单但每一条我都见过有人栽在上面。尤其是审计日志写满磁盘这种问题平时不显眼出事的时候特别致命。5. 实测中那些文档不会告诉你的坑5.1 路径规范化最隐蔽的绕过入口前面提过路径问题这里展开讲。假设你的策略是允许读./data目录你在代码里判断路径是否以./data开头。攻击者或者一个聪明的模型可以用这些路径绕过./data/../config/secret.txt字符串上以./data开头实际指向 config 目录。./data/./../../etc/passwd同理。符号链接./data/link指向外部目录读 link 等于读外部。正确的做法是先把路径规范化成绝对路径解析掉所有..和符号链接再判断是否在允许的根目录之下。这一步几乎所有自研外壳都会漏而 OpenShell 这类成熟工具通常内置了处理。如果你在自研务必补上。5.2 命令执行的参数注入允许执行某个命令不代表允许执行它的所有参数。经典例子是find命令的-exec参数可以执行任意命令tar的--to-command参数同理。你放行了find等于间接放行了任意命令执行。应对思路有两个一是只放行参数白名单明确列出允许的参数二是对参数做语义校验识别出危险参数直接拒绝。前者更安全但更死板后者灵活但需要维护规则。我的建议是对高风险命令用白名单对低风险命令用语义校验。5.3 超时控制的假超时很多实现用subprocess的timeout参数做超时以为万事大吉。但这里有个坑timeout到期后它杀的是直接子进程如果这个子进程又 fork 了孙进程孙进程可能变成孤儿继续跑。结果就是主进程超时了但后台还在偷偷执行。正确的做法是把子进程放进独立的进程组超时时杀整个进程组。在类 Unix 系统上通常通过设置进程组 ID 然后对负的 PID 发信号来实现。这个细节不处理超时控制就是纸糊的。5.4 审计日志的写丢失高并发场景下多个 Agent 同时写审计日志如果实现不当会出现日志丢失或交错。我遇到过用普通文件追加写、结果两条日志粘在一起的情况排查时看得头皮发麻。解决办法是每条日志独立成行、写入时加锁或用队列串行化。如果性能要求高可以先写内存队列再由单独的线程批量落盘。但要注意进程崩溃时内存队列里的日志会丢所以关键操作比如危险操作被拦截建议同步落盘。6. 策略调优从能用到好用的进阶思路6.1 基于审计日志做策略收敛策略上线一段时间后你会积累一批审计日志。这时候做一次策略收敛很有价值。具体做法是统计每个能力项的实际调用频率和调用参数分布把从未被调用过的能力项删掉把调用参数范围收窄到实际用到的区间。我做过一次这样的收敛把某个 Agent 的能力项从 15 个减到 6 个参数范围也大幅收窄。结果是安全性明显提升而 Agent 的任务完成率几乎没变——因为那 9 个能力项本来就是以防万一加上去的实际根本没用。6.2 分级策略不同任务用不同外壳不是所有任务都需要同一套策略。一个只读数据的分析任务和一个需要写文件、跑构建的编码任务风险等级完全不同。与其用一套最大公约数策略不如做分级。我的做法是定义几档策略模板readonly只读、workspace工作目录内读写、build允许执行构建命令、full全能力仅限隔离环境。每个 Agent 任务启动时指定用哪一档。这样既保证了安全又避免了一刀切导致的效率损失。6.3 人工确认环节的插入点有些操作风险高但确实必要比如删除文件、发送外部请求。这类操作不适合完全禁止也不适合完全放行适合人工确认。OpenShell 这类工具通常支持在策略里配置需要确认的动作。插入确认环节的关键是选对插入点。确认太频繁用户会被烦死确认太少又起不到把关作用。我的经验是只在不可逆 影响范围超出工作目录的操作上要求确认。工作目录内的可逆操作放手让 Agent 做效率优先。7. 关于 OpenShell 这类工具我的一些真实体会用了这么久我最大的体会是外壳的价值不在于限制而在于让你敢放手。没有外壳的时候你不敢给 Agent 太多能力因为它一旦乱来你收不住有了外壳你可以放心地把能力给足因为你知道边界在哪里、越界会被拦下。这种敢放手带来的效率提升远比外壳本身的开销大。另一个体会是策略配置是个持续迭代的过程不是一次性的任务。你不可能第一版就配得完美一定是配置—运行—看日志—调整这样循环几轮。所以别指望一次配到位把审计和迭代机制建好比追求完美初版重要得多。最后分享一个我踩过的坑早期我为了省事把审计日志和业务日志混在一起写。结果排查 Agent 问题时得在几万行业务日志里捞那几条审计记录效率极低。后来把审计日志单独拆出来按会话 ID 组织排查效率直接翻倍。如果你正准备接入这一点建议一开始就做对。这套东西说到底是把软件工程里最小权限默认拒绝可观测性这些老原则用在了 AI Agent 这个新场景上。原则不新但用对地方价值就出来了。
OpenShell 这个名字第一次听到的人大概率会猜错方向。有人以为是某个新出的终端工具有人觉得是操作系统里的一个组件还有人直接把它和容器、沙箱联系起来。我最初接触它的时候也走了弯路翻了半天文档才发现它真正解决的问题比这些猜测都要具体给 AI 智能体Agent提供一个可编程、可审计、可约束的执行外壳。换句话说当你的大模型不再只是聊天而是要真正去调用工具、读写文件、执行命令、访问网络的时候OpenShell 就是那个夹在模型和真实世界之间的安全驾驶舱。这篇内容适合三类人看一是正在做 Agent 应用、被模型乱调工具折磨过的开发者二是对 AI 执行安全、权限隔离感兴趣的技术负责人三是想搞清楚 OpenShell 到底值不值得引入的技术选型者。我会从它要解决的核心痛点讲起拆解它的策略模型、执行链路、权限边界再给出一套可以照着跑的落地步骤最后把我踩过的坑和实测经验摊开讲。全文基于 OpenShell 这类智能体外壳/执行沙箱的通用设计思路展开具体 API 名称以你实际使用的版本为准但底层逻辑是相通的。1. 为什么裸奔的 Agent 一定会出事1.1 从能聊天到能动手的那道坎大模型本身是个纯文本进、纯文本出的东西。它不会真的去删你的文件也不会真的去发一封邮件——除非你给了它工具。所谓 Agent本质就是模型 工具调用循环模型输出一个结构化的调用意图你的程序去执行再把结果喂回模型如此往复。问题就出在你的程序去执行这一步。绝大多数人第一版 Agent 是这么写的模型说要执行什么命令就直接subprocess.run()跑模型说要读哪个文件就直接open()读。这在 demo 阶段爽得飞起一旦上线就是灾难。我见过最离谱的一个案例是模型在调试过程中自己拼出了一条递归删除的命令幸好当时跑在测试机上否则整个项目目录就没了。OpenShell 这类工具存在的根本理由就是把模型想做什么和系统实际执行什么这两件事彻底分开。模型永远只能申请真正执行与否、以什么权限执行、执行结果给不给它看全部由外壳这一层说了算。1.2 三类典型事故暴露的是同一个缺口我把实际遇到过和听说过的 Agent 事故归成三类你会发现它们指向的是同一个设计缺陷。第一类是越权访问。模型为了完成帮我总结一下项目这个任务顺手去读了~/.ssh或者环境变量里的密钥文件。它没有恶意它只是觉得这些文件可能相关。但结果就是敏感信息进了模型的上下文甚至可能被写进日志。第二类是不可逆操作。删除、覆盖、格式化、发送——这类操作一旦执行就没有回头路。模型对危险的判断力和人类完全不在一个量级它可能因为一个措辞模糊的指令就触发破坏性动作。第三类是资源失控。模型陷入循环反复调用同一个工具或者某个命令挂死不返回把整个 Agent 进程拖垮。没有超时、没有配额、没有熔断一个 bug 就能烧掉你一整晚的算力。这三类问题的共同点是它们都不是模型能力的问题而是约束的问题。你不可能靠提示词让模型永远不犯错你只能在外壳层面把犯错的代价控制住。这就是 OpenShell 的核心价值主张。1.3 外壳不是加个 if 判断那么简单很多人第一反应是那我写个函数判断一下命令里有没有rm -rf不就行了这种字符串黑名单的思路我劝你趁早放弃。原因很简单绕过方式太多了。rm -r -f、rm --recursive --force、用变量拼接、用 base64 解码后再执行、调用一个自己写的脚本间接删除……你永远列不全黑名单。安全领域有个基本原则叫默认拒绝deny by default黑名单是默认允许方向就反了。OpenShell 采用的是白名单 策略引擎的思路默认什么都不让做你显式声明允许哪些能力、在什么条件下允许、允许到什么程度。这个思路的转变是从堵漏洞到划边界是质的区别。理解了这一点你才能理解它后面所有的设计。2. OpenShell 的策略模型能力、约束、审计三件套2.1 能力Capability把权限拆成最小颗粒OpenShell 的第一个核心概念是能力。它不给你一个笼统的执行权限而是把 Agent 能做的事拆成一个个独立的能力单元。常见的能力维度包括文件系统能力读、写、创建、删除而且要细化到路径级别。比如允许读/workspace/data但不允许碰/workspace/config。命令执行能力允许执行哪些可执行文件是否允许带参数是否允许管道和重定向。网络能力允许访问哪些域名或地址段允许哪些协议和端口。环境能力能读取哪些环境变量能访问哪些系统资源。这种拆法的好处是你可以精确地表达这个 Agent 只需要读数据、算结果、写报告这样的意图而不必给它一整套系统权限。最小权限原则Principle of Least Privilege在这里不是口号而是可以直接配置的东西。我个人的经验是能力配置要从零开始加而不是从全量开始减。你先假设 Agent 什么都不能做然后根据它实际完成的任务一项一项往上加。每加一项都问自己这项能力如果被滥用最坏结果是什么能接受就加不能接受就换方案。2.2 约束Constraint给能力加上条件和上限光有能力还不够你还得控制用多少什么时候能用。这就是约束层的作用。OpenShell 里常见的约束类型有这么几种数量约束比如最多执行 50 次命令、最多写 10 个文件。防止模型陷入循环或者被诱导做批量操作。时间约束单次命令最长执行 30 秒整个会话最长 10 分钟。超时直接终止避免挂死。空间约束写入的总字节数上限、单个文件大小上限。防止磁盘被写爆。条件约束某些能力只在特定条件下开放。比如只有在工作目录内才允许写文件或者只有在用户显式确认后才允许执行删除。约束的价值在于它把绝对安全这个做不到的目标换成了风险可控这个能做到的目标。你没法保证 Agent 永远不犯错但你可以保证它犯的错在可承受范围内。2.3 审计Audit每一次执行都留下痕迹第三个支柱是审计。OpenShell 会把每一次能力调用完整记录下来谁申请的、申请了什么、策略怎么判定的、执行结果是什么、耗时多久。这份日志有两个用途。一是事后追溯。当 Agent 做出了意料之外的行为你能精确还原它当时想做什么被允许做什么实际做了什么。没有审计日志排查 Agent 问题基本靠猜。二是策略调优。你翻日志会发现很多你当初以为需要的能力实际上 Agent 从来没用过而有些你没预料到的调用频繁出现。根据真实日志去收紧或放宽策略比拍脑袋配置靠谱得多。提示审计日志本身也可能包含敏感信息比如命令参数里的路径、文件名。日志的存储和访问权限要单独管理别让审计系统变成新的泄露点。3. 一次工具调用在外壳里到底经历了什么3.1 从模型输出到实际执行的完整链路理解执行链路是排查问题的前提。我把 OpenShell 处理一次工具调用的过程拆成六个阶段你可以对照自己的实现看看卡在哪一环。第一阶段意图解析。模型输出的是一段结构化文本通常是 JSON描述它想调用哪个工具、传什么参数。外壳首先要做的是解析这段文本校验格式是否合法。格式都不对的调用直接拒绝不要试图猜模型的意思。第二阶段能力映射。把工具调用映射到具体的能力项。比如调用 shell 工具执行ls映射到命令执行能力读取 report.txt映射到文件读取能力。这一步决定了后面用哪条策略去判定。第三阶段策略判定。拿能力项和参数去匹配策略规则。命中允许规则就放行命中拒绝规则就拦截没有匹配任何规则则按默认策略处理通常是拒绝。这一步是整个外壳的大脑。第四阶段执行前准备。放行之后还要做执行环境的准备切换到受限的工作目录、设置资源限制、准备超时控制、注入必要的环境变量。这一步容易被忽略但它决定了执行是否真的被关在笼子里。第五阶段实际执行。在受控环境下真正跑起来。执行过程中要持续监控资源占用和超时一旦越界立即终止。第六阶段结果处理与回传。把执行结果标准输出、标准错误、退出码做必要的截断和脱敏再回传给模型。注意回传的内容也要过一遍策略别让执行结果里的敏感信息直接进模型上下文。3.2 为什么执行前准备是最容易被做错的一环我见过不少自己实现的简易外壳策略判定做得挺认真但执行前准备几乎没做。结果就是策略上写着只能访问工作目录实际执行时进程的工作目录根本没切模型一个相对路径就跳出去了。这里的关键认知是策略判定是逻辑层的约束执行环境是物理层的约束两者必须同时到位。逻辑层告诉你应该只允许访问 A 目录物理层要确保即使逻辑层被绕过进程也真的访问不到 B 目录。前者靠代码后者靠操作系统提供的隔离机制比如工作目录切换、资源限制、权限降级。举个具体的例子。假设你允许 Agent 执行python命令但只允许它运行工作目录下的脚本。逻辑层你可以检查命令参数里的脚本路径。但如果 Agent 执行的是python -c import os; os.system(...)参数里根本没有脚本路径你的检查就失效了。这时候物理层的隔离——比如把进程关在一个只能看到工作目录的环境里——才是真正的兜底。3.3 结果回传的截断与脱敏别省这一步模型上下文是有限的执行结果动辄几万行全塞回去既浪费 token 又可能触发长度限制。所以结果回传前必须截断。但截断有个坑你不能简单地从中间截因为命令的关键信息比如报错往往在末尾。我的做法是头尾保留 中间省略保留前 N 行和后 M 行中间用省略标记代替。对于标准错误优先保留因为报错信息更重要。对于超长单行输出还要做行内截断否则一行几万个字符照样撑爆上下文。脱敏则是另一层。执行结果里可能包含路径、用户名、内部地址等信息。如果这些不该进模型上下文就要在回传前替换掉。这一步很多人觉得没必要直到某次审计发现模型上下文里躺着一堆内部路径才后悔。4. 把 OpenShell 跑起来从零到可用的落地步骤4.1 环境准备与最小可用配置假设你已经拿到了 OpenShell 的代码或包第一步不是急着写策略而是先跑通一个什么都不允许的最小配置。这一步的目的是验证外壳本身能正常工作把环境问题和策略问题分开排查。最小配置大概长这样以伪配置为例具体字段名以你的版本为准shell: default_policy: deny # 默认拒绝这是安全基线 audit: enabled: true log_path: ./audit.log limits: max_commands: 20 command_timeout: 30 max_output_bytes: 1048576 capabilities: [] # 先什么都不给跑起来之后你让 Agent 随便调一个工具应该看到它被拒绝并且审计日志里记录了这次拒绝。如果这一步就失败了说明外壳没接对先别往下走。注意default_policy: deny是必须的。我见过有人图省事设成allow想着先跑通再收紧结果这个临时配置一直留到了生产环境。4.2 按任务反推能力清单环境跑通后开始加能力。方法不是猜 Agent 需要什么而是让它先失败看它申请什么。具体操作是保持默认拒绝让 Agent 去完成一个真实任务它会因为权限不足而失败失败信息里会告诉你它想调用什么能力。你据此逐条添加。举个例子任务是读取 data 目录下的 CSV统计行数把结果写到 report.txt。Agent 会依次申请读data/*.csv、执行统计命令或者它自己写代码算、写report.txt。你对应的能力配置就是capabilities: - type: file_read paths: [./data/*.csv] - type: file_write paths: [./report.txt] - type: command_exec executables: [python3] allow_args: true注意这里executables只放行了python3没放行rm、curl这些。Agent 如果真想删文件或联网会被直接拦下。这就是白名单的威力。4.3 用真实流量压一遍策略配置写完不代表完事。你得用一批真实或接近真实的请求去压一遍看策略会不会误伤正常操作或者漏放危险操作。我一般会准备三类测试用例用例类型目的示例正常用例验证合法操作不被误拦读指定 CSV、写指定报告边界用例验证策略边界是否精确读同目录下未授权的文件、写超出范围的路径恶意用例验证危险操作被拦截尝试执行删除命令、尝试访问敏感路径三类都跑通策略才算基本可用。这里有个经验边界用例最容易暴露配置漏洞。比如你配了./data/*.csv那./data/../config/secret.txt算不算命中取决于你的路径规范化做得好不好。这类问题不测是发现不了的。4.4 上线前的最后三道检查正式接入生产前我会强制过三道检查。第一道默认策略确认。再确认一遍default_policy是deny且没有任何临时放行的残留配置。第二道审计开关确认。审计必须是开着的且日志路径可写、有轮转策略否则日志会把磁盘写满。第三道熔断确认。确认数量、时间、空间三类约束都配了合理值且触发后的行为是终止并告警而不是静默忽略。这三道检查看着简单但每一条我都见过有人栽在上面。尤其是审计日志写满磁盘这种问题平时不显眼出事的时候特别致命。5. 实测中那些文档不会告诉你的坑5.1 路径规范化最隐蔽的绕过入口前面提过路径问题这里展开讲。假设你的策略是允许读./data目录你在代码里判断路径是否以./data开头。攻击者或者一个聪明的模型可以用这些路径绕过./data/../config/secret.txt字符串上以./data开头实际指向 config 目录。./data/./../../etc/passwd同理。符号链接./data/link指向外部目录读 link 等于读外部。正确的做法是先把路径规范化成绝对路径解析掉所有..和符号链接再判断是否在允许的根目录之下。这一步几乎所有自研外壳都会漏而 OpenShell 这类成熟工具通常内置了处理。如果你在自研务必补上。5.2 命令执行的参数注入允许执行某个命令不代表允许执行它的所有参数。经典例子是find命令的-exec参数可以执行任意命令tar的--to-command参数同理。你放行了find等于间接放行了任意命令执行。应对思路有两个一是只放行参数白名单明确列出允许的参数二是对参数做语义校验识别出危险参数直接拒绝。前者更安全但更死板后者灵活但需要维护规则。我的建议是对高风险命令用白名单对低风险命令用语义校验。5.3 超时控制的假超时很多实现用subprocess的timeout参数做超时以为万事大吉。但这里有个坑timeout到期后它杀的是直接子进程如果这个子进程又 fork 了孙进程孙进程可能变成孤儿继续跑。结果就是主进程超时了但后台还在偷偷执行。正确的做法是把子进程放进独立的进程组超时时杀整个进程组。在类 Unix 系统上通常通过设置进程组 ID 然后对负的 PID 发信号来实现。这个细节不处理超时控制就是纸糊的。5.4 审计日志的写丢失高并发场景下多个 Agent 同时写审计日志如果实现不当会出现日志丢失或交错。我遇到过用普通文件追加写、结果两条日志粘在一起的情况排查时看得头皮发麻。解决办法是每条日志独立成行、写入时加锁或用队列串行化。如果性能要求高可以先写内存队列再由单独的线程批量落盘。但要注意进程崩溃时内存队列里的日志会丢所以关键操作比如危险操作被拦截建议同步落盘。6. 策略调优从能用到好用的进阶思路6.1 基于审计日志做策略收敛策略上线一段时间后你会积累一批审计日志。这时候做一次策略收敛很有价值。具体做法是统计每个能力项的实际调用频率和调用参数分布把从未被调用过的能力项删掉把调用参数范围收窄到实际用到的区间。我做过一次这样的收敛把某个 Agent 的能力项从 15 个减到 6 个参数范围也大幅收窄。结果是安全性明显提升而 Agent 的任务完成率几乎没变——因为那 9 个能力项本来就是以防万一加上去的实际根本没用。6.2 分级策略不同任务用不同外壳不是所有任务都需要同一套策略。一个只读数据的分析任务和一个需要写文件、跑构建的编码任务风险等级完全不同。与其用一套最大公约数策略不如做分级。我的做法是定义几档策略模板readonly只读、workspace工作目录内读写、build允许执行构建命令、full全能力仅限隔离环境。每个 Agent 任务启动时指定用哪一档。这样既保证了安全又避免了一刀切导致的效率损失。6.3 人工确认环节的插入点有些操作风险高但确实必要比如删除文件、发送外部请求。这类操作不适合完全禁止也不适合完全放行适合人工确认。OpenShell 这类工具通常支持在策略里配置需要确认的动作。插入确认环节的关键是选对插入点。确认太频繁用户会被烦死确认太少又起不到把关作用。我的经验是只在不可逆 影响范围超出工作目录的操作上要求确认。工作目录内的可逆操作放手让 Agent 做效率优先。7. 关于 OpenShell 这类工具我的一些真实体会用了这么久我最大的体会是外壳的价值不在于限制而在于让你敢放手。没有外壳的时候你不敢给 Agent 太多能力因为它一旦乱来你收不住有了外壳你可以放心地把能力给足因为你知道边界在哪里、越界会被拦下。这种敢放手带来的效率提升远比外壳本身的开销大。另一个体会是策略配置是个持续迭代的过程不是一次性的任务。你不可能第一版就配得完美一定是配置—运行—看日志—调整这样循环几轮。所以别指望一次配到位把审计和迭代机制建好比追求完美初版重要得多。最后分享一个我踩过的坑早期我为了省事把审计日志和业务日志混在一起写。结果排查 Agent 问题时得在几万行业务日志里捞那几条审计记录效率极低。后来把审计日志单独拆出来按会话 ID 组织排查效率直接翻倍。如果你正准备接入这一点建议一开始就做对。这套东西说到底是把软件工程里最小权限默认拒绝可观测性这些老原则用在了 AI Agent 这个新场景上。原则不新但用对地方价值就出来了。
