AI 编码代理新增任务时，常会生成 shell 命令、安装脚本和依赖调用。开发者难以逐行确认这些命令会覆盖哪些文件、访问哪些网络。任务运行器 Lask 在 0.15.0 中加入 within 机制：命令可访问的文件和网络先被声明，类型检查器静态验证。它把问题前移到运行前：系统能否先回答 AI 生成任务能访问什么。
人工审查变弱，机器检查被推到台前
素材指出，即使代码由人编写，靠阅读发现恶意代码也不容易。2024 年 3 月，xz Utils 后门并非通过普通代码阅读发现，而是 PostgreSQL 开发者 Andres Freund 调查 SSH 登录异常 CPU 占用时追踪出来。依赖代码被阅读的程度更低：一项覆盖四个包注册表的研究显示，52.5% 的更新只得到部分代码审查，只有 9.0% 的包每次更新都被完整审查。S3C2 供应链安全峰会报告也认为，目前缺少可靠的自动化方法识别恶意提交，人工审查容易出错。
AI 编码工具增加了需要阅读的代码量。哈佛大学一篇基于 655 家企业开发数据的工作论文估算，采用 AI 代理后，新增代码行数上升 44.0%，打开的 pull request 数量上升 35.7%，从打开到合并的平均时间增长 56.1%。作者认为代码审查成为瓶颈。另一项针对 802 名开发者的研究显示，审查者负担大约翻倍。文章作者据此认为，需要不依赖人工逐行阅读的机器检查。
依赖安装脚本难以用形式化证明覆盖
形式化验证被视为一种可能方向。Martin Kleppmann 在 2025 年 12 月预测，AI 将推动形式化验证走向主流，因为 AI 可以降低编写证明的成本。但素材同时强调，编写和阅读形式化规范仍需要专业知识；证明只能保证代码符合规范，规范本身仍由人制定。
在构建和安装任务中，这一方法更难落地。npm install 会执行第三方依赖的安装脚本，通常没有规范说明这些脚本应该做什么。Unit 42 对 npm 威胁的概述称，许多入侵依赖 preinstall 或 postinstall 钩子窃取密钥。在 TanStack 事件中，注入 CI 的代码收集了 NPM_TOKEN 和 GITHUB_TOKEN；另有报道称，4 月出现的一种自传播蠕虫利用窃取的 npm token 发布携带恶意代码的版本。常见建议是 ignore-scripts，但部分包需要脚本，全部禁用并不总是可行。
从证明输出正确，到限制输出边界
因此，研究和工程实践开始转向边界控制：不逐条判断 AI 输出是否正确，而是检查 AI 输出不能越过哪些限制。Containment Verification 不假设模型如何行为，而是把 AI 视为能生成框架类型范围内任意值的组件，并用 Dafny 证明代理框架对所有可能值都执行边界策略。作者称，这种保证不依赖模型是否对齐。Google DeepMind 的 CaMeL 在模型外放置解释器，记录每个值来源，并在工具调用前对照策略检查，以防御提示注入。Anthropic 在 Agent SDK 文档中区分权限检查与隔离，称命令解析和权限规则匹配是权限门，不是沙箱。
素材将这些机制归纳为不同时间点的防线：静态边界检查在运行前查看容器、沙箱等隔离机制及配置；权限检查在即将运行前判断操作是否允许执行；权限规则和确认提示在执行关口把关。Lask 的 within 与这一方向一致：先声明文件和访问范围，再静态验证，命令在声明的 Docker 镜像容器中运行。
对 AI 编程工具链而言，这意味着安全重点正在扩展：不只是读懂 AI 生成的代码，还要把依赖安装、文件写入、网络访问和执行环境纳入可声明、可检查、可限制的范围内。运行前的访问清单，可能成为 AI 编码代理进入工程流程的基础配置。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/ai-bian-ma-dai-li-sheng-cheng-de-ren-wu-hui-fang-wen-shen
