# Coding Agent 还在装环境，第三方代码可能已经跑完了

> 原标题：Coding Agent 还在配置环境，第三方代码已经运行了

- 来源：Computing Life · Share · 鸭哥调研
- 发布时间：2026-07-20T00:00:00.000Z
- AX AI 日报：https://ai-daily.ax0x.ai/items/45636
- 原文：https://yage.ai/share/coding-agent-setup-install-boundary-20260720.html

## 摘要

一篇预印本论文指出，让 Coding Agent“先把项目跑起来”本身就包含了一次代码执行。Agent 读 README 和依赖配置后调用 pip、npm 或 Cargo 安装软件包，而 Python 的 setup.py、npm 的 postinstall、Cargo 的 build.rs 都能在安装时运行代码。作者构造了 12 个场景、5 类攻击，...

## 推荐理由

这篇预印本把 Coding Agent 的依赖安装环节当成攻击面来拆解，12 个场景、5 类攻击、9 种配置测试，信息量扎实。扣分项是预印本状态，没有独立复现，攻击场景是构造的而非真实在野案例。但选题确实打中了 Agent 工作流里一个很少被讨论的安全盲区——让模型“先把项目跑起来”这个动作本身就隐含了一次代码执行，而且大部分 Agent 默认不会拦。我会先打个折，因为还没经过同行评审，但话题本身值得从业者看一眼。

## 锐评

这篇预印本点出了一个很容易被忽略的时间差：我们以为 Agent 还在配环境，其实 pip install 或 npm install 那一步就已经在跑代码了。Python 的 setup.py、npm 的 postinstall、Cargo 的 build.rs 都能在安装时执行，而最终 diff 只记录仓库文件变更，不会告诉你安装脚本刚才干了什么。

作者构造了 12 个场景、5 类攻击，测了 9 种模型和客户端的组合。明显拼错的包名基本都被拦住了，但换成更接近真名的变体、加一个攻击者控制的额外 registry，或者指定一个已知有漏洞的旧版本，很多配置就放行了。这里有个关键限制：实验是构造场景，不是对真实攻击的统计，也没有独立复现。

文章给出的建议很具体：安装前先解析出包名、来源和版本，对不上预期就暂停，等开发者确认；通过检查的安装也要跑在受限环境里。但正文没披露这套规则在真实项目里的误报率，也没测不同客户端实现这些检查的工程成本。如果团队用了内部 registry 或 Git 依赖，规则怎么配、谁来维护，这些落地细节都还是空白。