AI 写更多代码后，我们如何安全治理？两个开源项目给出方向

当 AI 成为代码库的主要贡献者

AI 编程代理正在从辅助工具演变为软件开发生态中的核心力量。它们不再只是补全几行代码，而是编写大部分代码、修改仓库、调用工具、访问系统、做出决策，甚至可能与其他代理相互协调。

这带来一个反直觉的判断：随着 AI 承担更多编码工作，人类的介入（human-in-the-loop）不是变得可有可无，反而可能更加关键。问题在于——负责审查、引导和治理这些 AI 开发代理的人，本身也需要面向 AI 时代的新工具和新能力。而这一点，目前的行业讨论远远不够。

这正是 Ikarus AI Safety Tech 团队在 Reddit 上抛出的核心论点：AI 会构建我们更多的软件，人类必须变得更擅长治理它。

SafeAI：在代理进入工作流之前先看清它

第一个项目 SafeAI 定位为「静态 AI 代理安全与能力分析器」。它的核心思路很直接：在一个 AI 代理成为开发工作流的一部分之前，我们应当能够理解它的能力边界。

具体来说，SafeAI 试图回答这样几个问题：

• 这个代理具备哪些能力（capabilities）？
• 它能调用哪些工具（tools）？
• 它的**自主性（autonomy）**有多高？
• 它拥有怎样的记忆（memory）与身份（identity）？
• 它可能引入哪些潜在风险？

这种「先分析、后接入」的思路，本质上是把传统软件供应链的安全审查前移到了 AI 代理层面。当代理拥有了访问系统、执行操作的权限，它就不再只是一段代码，而是一个具备行为能力的实体，理应在进入生产环境前被评估。

「静态分析」这一定语值得特别注意。静态分析（Static Analysis）是指在不实际运行程序的情况下对其进行检查，与之对应的是动态分析（需要实际执行代码才能观测行为）。将静态分析应用于 AI 代理，意味着通过检查代理的配置文件、系统提示（System Prompt）、工具定义（Tool Definitions）和权限声明等元数据，来推断其潜在行为和风险边界，而无需真正让代理运行起来。这种方法的优势在于低风险、可重复、可在 CI/CD 流水线中自动化；局限则在于，AI 代理的实际行为往往高度依赖运行时上下文，静态分析无法完整覆盖所有涌现行为（emergent behavior）。因此，SafeAI 的定位更类似于代码 linter 或 SAST（静态应用安全测试）工具，是第一道防线，而非完整的安全保证。

OpenPulse：给开源依赖装上「预警雷达」

第二个项目 OpenPulse 聚焦于另一个长期存在但常被忽视的痛点——开源软件生态的依赖情报。

现代软件往往依赖成千上万个外部项目，而这些项目始终处于变动之中：它们会更新迭代、被废弃（deprecated）、走到生命周期终点（EOL）、暴露出漏洞、更换维护者，或者产生其他最终会波及自身系统的信号。

OpenPulse 想做的，是帮助团队在这些变化演变成「意外」之前就提前看见它们。换句话说，它把被动的「事后救火」变成主动的「事前预警」。对于依赖庞大的现代工程团队而言，这类依赖智能可以显著降低供应链层面的不确定性。

软件供应链安全（Software Supply Chain Security）近年来已成为行业重点议题，2020 年的 SolarWinds 事件和 2021 年的 Log4Shell 漏洞让整个业界意识到，攻击者可以通过污染上游依赖来大规模入侵下游系统。在此背景下，「依赖情报」（Dependency Intelligence）不仅包括已知漏洞（CVE）的追踪，还延伸到更软性的信号：项目是否进入了无人维护状态、核心维护者是否发生变更（维护者账号被接管是近年新兴攻击面）、许可证是否悄然改变等。EOL（End of Life）是指软件官方停止提供安全更新和技术支持的时间节点，使用 EOL 依赖意味着已知漏洞将永久无人修复。OpenPulse 所做的，正是将这些分散在 GitHub、npm、PyPI、OSV 数据库等不同来源的信号汇聚起来，转化为对工程团队有实际决策价值的预警。

两个项目背后的共同命题

SafeAI 与 OpenPulse 表面上分别针对「AI 代理安全」和「开源依赖治理」两个不同问题，但它们指向同一个更大的探索方向：

AI 将构建我们更多的软件，人类必须在治理它这件事上做得更好。

一个负责评估进入系统的智能体，一个负责监控系统所依赖的外部世界——二者共同构成了对「AI 驱动软件开发」这一新范式的治理框架雏形。这种组合思路值得关注，因为它把讨论从「AI 能写多好的代码」转向了「我们如何安全地管理 AI 写的代码」，后者往往才是工程组织真正头疼的地方。

「人类介入」（Human-in-the-Loop，HITL）在 AI 系统设计中特指在关键决策节点保留人类审批或干预的机制，最初广泛应用于机器学习模型训练（人工标注、反馈强化）和高风险自动化场景（如无人驾驶、医疗诊断）。随着 AI 代理被赋予直接操作代码仓库、执行终端命令、调用外部 API 等能力，HITL 的内涵在软件工程语境下正在被重新定义——它不再只是「批准一次模型预测」，而是涉及访问控制策略、变更审查流程、异常行为熔断机制等系统性设计。SafeAI 和 OpenPulse 可以被理解为两种不同维度的 HITL 基础设施：前者在「引入新代理」这一节点提供决策依据，后者在「依赖生命周期」维度持续提供情报输入，二者共同试图让人类的干预从被动响应变为有信息支撑的主动治理。

招募「创始倡导者」：他们要的是质疑，而非吹捧

团队坦言不想闭门造车，正在寻找第一批「创始倡导者（Founding Advocates）」。目标人群包括开发者、安全工程师、AI 构建者、开源维护者、DevOps/SRE 从业者、架构师，以及对这一问题真正好奇的人。

有意思的是他们的态度：不希望有人盲目推广，反而更欢迎唱反调。

告诉我们哪里错了。试用工具，打破我们的假设，提出我们没想到的能力，告诉我们什么才能让这些工具在真实工程组织中真正有用。

这种开放姿态在开源社区并不少见，但明确把「挑战假设」放在首位，说明项目仍处于早期塑形阶段，欢迎外部视角介入定义「负责任的 AI 驱动软件开发」应该长什么样。

感兴趣的开发者可以在 GitHub 上查看两个项目：

• SafeAI：ikaruscareer/SafeAI
• OpenPulse：ikaruscareer/OpenPulse

写在最后

这两个项目目前仍处于非常早期的阶段，更多是一个开放的命题和邀请，而非成熟的解决方案。但它们提出的问题切中要害：当 AI 代理越来越深地嵌入软件开发流程，治理能力的缺口正在扩大。

无论 SafeAI 和 OpenPulse 最终能否成为主流工具，它们所代表的思路——为 AI 时代的软件治理者提供配套的智能工具——都是一个值得整个社区认真对待的方向。