Agent 发明的依赖：一个破除迷思的 FAQ
一位开发者在 Dev.to 上发表文章，以 FAQ 的形式探讨了一个有趣的现象：AI 编码 Agent 在工作过程中可能会"发明"出项目中原本不存在的依赖。文章通过一个重构的事故场景，揭示了当团队把 Agentic 循环当作架构审查时可能出现的问题，并回答了关于这个现象的常见疑问。
背景：一个重构的事故场景
文章以一个重构的事故场景开场：
一个后端开发双人组看着他们的编码 Agent 自信地完成了六个步骤，生成了一个整洁的 Pull Request。测试套件全部通过，代码看起来也很合理。但在代码审查中，他们发现了一个问题：Agent 引入了一个项目中原本不存在的依赖。
这个依赖不是 Agent 凭空捏造的——它是一个真实存在的开源库。但问题是：
- 项目之前没有使用这个库
- 引入这个库没有经过团队的讨论和决策
- Agent 认为这个库是"标准做法"，所以自动引入了
- 测试通过了，因为 Agent 同时写了适配这个库的测试
这个场景揭示了一个重要问题：当 Agent 自动引入依赖时，团队可能在不知情的情况下增加了项目的复杂性、安全风险和维护负担。
FAQ：关于 Agent 发明依赖的常见疑问
Q1：Agent 为什么会发明依赖？
A：Agent 发明依赖有几个原因：
- 训练数据的影响：Agent 在训练过程中见过大量使用各种依赖的代码，它会倾向于使用"常见"的库来解决问题
- 缺乏项目上下文：Agent 可能没有完全理解项目的技术栈和约束，会用它认为"最好"的方式来解决问题
- 优化目标偏差：Agent 的目标是"完成任务"，而不是"最小化依赖"。它可能会引入依赖来更快地完成任务
- 幻觉（Hallucination）：在某些情况下，Agent 可能会"幻觉"出一个它认为存在但实际上不存在的 API 或库
- 缺乏架构意识：Agent 可能不理解项目的架构原则，比如"不引入新的运行时依赖"或"优先使用标准库"
Q2：这真的是个问题吗？测试不是通过了吗？
A：这确实是个问题，即使测试通过了。原因如下：
- 安全风险：每个新依赖都可能引入安全漏洞。更多的依赖意味着更大的攻击面
- 维护负担：每个依赖都需要维护——更新版本、修复兼容性问题、处理废弃通知
- 复杂性增加：更多的依赖意味着更复杂的依赖图，更难理解和调试
- 许可证风险：不同的依赖有不同的许可证，可能与项目的许可证不兼容
- 供应链风险：更多的依赖意味着更多的供应链攻击风险
- 技术债务：未经讨论引入的依赖可能不是最佳选择，未来可能需要替换
测试通过只说明功能正常，不说明依赖的引入是合理的。
Q3：如何防止 Agent 发明依赖？
A：有多种方法可以防止 Agent 发明依赖：
- 明确的约束指令：在给 Agent 的指令中明确说明"不要引入新的依赖"或"只能使用项目中已有的依赖"
- 依赖白名单：维护一个允许使用的依赖白名单，Agent 只能使用白名单中的依赖
- 架构决策记录（ADR）：要求 Agent 在引入新依赖时生成 ADR，说明为什么需要这个依赖、有什么替代方案、有什么风险
- 依赖检查工具：在 CI/CD 流水线中使用依赖检查工具（如
depcheck、npm audit、pip-audit），自动检测新引入的依赖 - 代码审查清单：在代码审查清单中加入"是否引入了新依赖"这一项，确保人工审查时关注这个问题
- 锁定依赖文件：将依赖锁定文件（如
package-lock.json、poetry.lock）纳入版本控制，任何变更都需要审查
Q4：如果 Agent 确实需要新依赖怎么办？
A：如果 Agent 确实需要新依赖，应该遵循以下流程：
Agent 提出建议：Agent 识别出需要新依赖，并提出建议，包括：
- 为什么需要这个依赖
- 这个依赖解决了什么问题
- 有什么替代方案（包括不使用依赖的方案）
- 这个依赖的许可证、维护状态、社区活跃度
- 引入这个依赖的风险
团队讨论和决策：团队讨论 Agent 的建议，做出是否引入的决策
正式引入：如果决策是引入，正式将依赖添加到项目中，并更新文档
Agent 实现：Agent 使用已批准的依赖来实现功能
关键是：Agent 可以建议依赖，但不能自动引入依赖。引入依赖的决策必须由人类做出。
Q5：如何检测 Agent 已经发明了依赖？
A：可以通过以下方式检测 Agent 发明的依赖：
- 依赖文件差异：比较 PR 中依赖文件（
package.json、pyproject.toml、go.mod等）的变更，任何新增的依赖都需要审查 - 导入语句扫描：扫描代码中的导入语句，检查是否有项目依赖中不存在的导入
- CI/CD 检查：在 CI/CD 中添加检查步骤，如果检测到新依赖，标记为需要人工审查
- 依赖审计工具：使用 Snyk、Dependabot、Renovate 等工具监控依赖变更
- 代码审查重点：在代码审查时，重点关注依赖文件的变更和新的导入语句
Q6：除了依赖，Agent 还可能发明什么？
A：Agent 可能发明的不仅仅是依赖，还包括：
- API 端点：Agent 可能发明项目中不存在的 API 端点
- 配置项：Agent 可能发明项目中不存在的配置项
- 环境变量：Agent 可能发明项目中不存在的环境变量
- 数据库表/字段：Agent 可能发明项目中不存在的数据库表或字段
- 文件路径：Agent 可能引用项目中不存在的文件路径
- 函数/方法：Agent 可能调用项目中不存在的函数或方法
- 类型/接口：Agent 可能使用项目中不存在的类型或接口
- 第三方服务：Agent 可能假设项目集成了某个第三方服务
这些"发明"可能不会导致测试失败（因为 Agent 同时写了适配的测试），但会在生产环境中导致问题。
Q7：如何从架构层面解决这个问题？
A：从架构层面，可以采取以下措施：
- 明确的架构边界：定义清晰的架构边界，Agent 只能在边界内操作
- 契约优先开发：先定义 API 契约、数据模型、接口，Agent 只能基于已定义的契约开发
- 类型系统：使用强类型语言和严格的类型检查，Agent 发明的不存在的类型会导致编译错误
- 编译时检查：利用编译器和静态分析工具，在编译时检测 Agent 的"发明"
- 测试策略：不仅测试功能，还测试依赖、配置、环境变量等非功能方面
- 架构测试：编写架构测试（如 ArchUnit、NetArchTest），自动检测违反架构规则的代码
Q8：Agentic 循环和架构审查有什么区别？
A：这是文章的核心观点之一。Agentic 循环和架构审查是两个不同的东西：
Agentic 循环：
- Agent 自主完成多步骤任务
- 每一步的输出是下一步的输入
- Agent 自己评估每一步的结果
- 目标是完成任务
架构审查：
- 人类专家审查系统的架构决策
- 关注长期影响、可维护性、可扩展性
- 考虑项目的约束和目标
- 目标是确保架构的合理性
把 Agentic 循环当作架构审查是危险的，因为：
- Agent 可能不理解项目的长期目标和约束
- Agent 倾向于快速完成任务，而不是做出最优的架构决策
- Agent 可能引入技术债务而不自知
- 架构决策需要人类的经验和判断力
最佳实践
基于以上分析，总结使用 AI 编码 Agent 时的最佳实践：
1. 明确 Agent 的边界
- 明确告诉 Agent 它可以做什么、不可以做什么
- 特别是：不要自动引入新依赖、不要修改架构、不要改变技术栈
- 将这些约束写入 Agent 的系统提示词
2. 人类在环中
- Agent 的输出必须经过人类审查
- 特别是依赖文件、配置文件、架构相关的变更
- 不要因为测试通过就跳过审查
3. 工具辅助检测
- 使用静态分析、依赖检查、架构测试等工具自动检测问题
- 在 CI/CD 流水线中集成这些检查
- 任何异常都需要人工确认
4. 渐进式授权
- 先让 Agent 做简单的、低风险的任务
- 逐步增加 Agent 的自主权
- 在每个阶段评估 Agent 的表现
5. 文档和沟通
- 记录项目的架构决策和技术约束
- 将这些信息提供给 Agent 作为上下文
- 团队成员之间沟通 Agent 的使用规范
总结
"Agent 发明的依赖"这个现象，揭示了使用 AI 编码 Agent 时的一个重要问题：Agent 可以高效地完成任务，但它的决策不一定符合项目的架构原则和长期利益。
核心要点：
- 现象：Agent 可能自动引入项目中原本不存在的依赖，即使测试通过
- 原因：训练数据影响、缺乏项目上下文、优化目标偏差、幻觉、缺乏架构意识
- 风险：安全风险、维护负担、复杂性增加、许可证风险、供应链风险、技术债务
- 防范：明确约束指令、依赖白名单、ADR、依赖检查工具、代码审查清单、锁定依赖文件
- 流程：Agent 可以建议依赖，但引入决策必须由人类做出
- 架构层面：明确架构边界、契约优先开发、类型系统、编译时检查、架构测试
- 关键区别：Agentic 循环不等于架构审查，架构决策需要人类的经验和判断力
对于正在使用或考虑使用 AI 编码 Agent 的团队来说，理解这个现象并采取相应的防范措施，是非常重要的。Agent 是强大的工具，但工具的使用需要人类的智慧和判断。
正如文章所暗示的，Agentic AI 的真正价值不在于让 Agent 自主做所有决策，而在于让 Agent 处理重复性的、低风险的工作，同时让人类专注于架构决策、技术选型和长期规划。这种人机协作的模式，才能最大化 AI 的价值，同时最小化风险。
原文链接：https://dev.to/devio_3007/the-dependency-the-agent-invented-a-myth-busting-faq-j3a