返回首页
24小时热榜
（原文链接为 <a href="https://www.theinformation.com/articles/deepseek-using-banned-nvidia-chips-race-build-next-model" rel="nofollow">https://www.theinformation.com/articles/deepseek-using-banne...</a>，但已被封锁）
我们正在发布关于编码代理治理的早期尝试，名为 Cupcake [1] - 这是一个开源的政策执行层，具有原生集成。您可以使用政策即代码（OPA/Rego）编写规则，Cupcake 通过 Hooks 将这些规则集成到代理运行时中。
<p>查看实际演示（仅限桌面）：<a href="https://cupcake-policy-studio.vercel.app/example-policies/security/protecting-paths?harness=claude-code&format=rego" rel="nofollow">https://cupcake-policy-studio.vercel.app/example-policies/security/protecting-paths?harness=claude-code&format=rego</a></p>
<p>帮助我们构建：<a href="https://github.com/eqtylab/cupcake" rel="nofollow">https://github.com/eqtylab/cupcake</a></p>
<p>我们是 EQTY Lab，我们的使命是可验证的人工智能（身份、来源和治理）。随着像 Claude Code 这样的强大代理的崛起，部署这些代理的人员需要能够进行自己的对齐和安全控制，这一点变得非常明显。我们不能仅仅依赖前沿实验室。</p>
<p>这就是为什么我们为 Claude Code [2] 创建了 Hooks 的功能请求，并在这些 Hooks 实现后转向不再依赖文件系统和操作系统级别的监控。Hooks 提供了我们所需的关键点：</p>
* 评估：检查代理的意图和行为。
* 预防：阻止不安全或不希望的行为。
* 修改：在执行之前调整代理的输出。
<p>使用 OPA/Rego 的政策即代码 - 尽管许多代理安全论文建议使用自创的领域特定语言（DSL）来构建类似的政策架构，但 Cupcake 基本上是建立在开放政策代理（OPA）及其政策语言 Rego [3] 之上的。</p>
<p>我们选择 Rego 是因为它：</p>
* 行业稳健：在企业 DevSecOps 和云原生环境中被广泛采用。
* 专门构建：为定义、管理和执行政策即代码提供独特且成熟的优势。
* 企业导向：这使得 Cupcake 与现有的企业治理框架兼容。
<p>Cupcake 采用 Apache-2.0 许可发布。我们将在 2026 年第一季度正式制定通往 v1.0.0 的路径。这是一个早期预览版本。Cupcake 的目标不是压制，而是确保代理能够快速运行而不崩溃。若要合作或联合，请联系 ramos@eqtylab.io。</p>
<p>[1] <a href="https://github.com/eqtylab/cupcake" rel="nofollow">https://github.com/eqtylab/cupcake</a></p>
<p>[2] <a href="https://github.com/anthropics/claude-code/issues/712" rel="nofollow">https://github.com/anthropics/claude-code/issues/712</a></p>
<p>[3] <a href="https://www.openpolicyagent.org/" rel="nofollow">https://www.openpolicyagent.org/</a></p>
嗨，HN，简而言之，我们开发了一个错误检测工具，效果非常好，尤其适用于应用后端。欢迎试用并告诉我们你的想法！
以下是详细内容。
--------------------------
我们最初的目标是解决技术债务。我们都见过有很多债务的代码库，因此对这个问题有着个人的看法，而人工智能似乎让这个问题变得更加严重。
技术债务似乎是一个很适合用人工智能解决的问题，因为：1）一小部分工作需要思考和战略，而大部分执行则相对机械；2）在解决技术债务时，通常是试图保留现有行为，只是改变实现方式。这意味着如果你能找到有效的方法来检测由于代码更改而导致的意外行为变化，就可以将其视为一个闭环问题。而我们知道如何做到这一点——这就是测试的作用！
因此，我们开始编写测试。测试创建了保护措施，使未来的代码更改更安全。我们的想法是：如果我们能测试得足够好，就可以以非常高的质量自动化许多其他技术债务工作。
我们构建了一个代理，可以为典型的代码库编写数千个新的测试，大多数是“合并质量”的。一些早期用户通过这种方式合并了数百个PR，但直观上这个工具总是给人一种“好但不够好”的感觉。我们自己偶尔使用它，通常感觉像是一项繁重的任务。
在这个时候，我们意识到：虽然我们最初的目标是编写好的测试，但我们构建了一个系统，经过一些调整，可能非常擅长发现错误。当我们在一些朋友的代码库上进行测试时，我们发现几乎每个代码库中都有大量潜伏的错误，我们能够标记出来。这些是严重的错误，足够有趣，以至于人们放下手头的工作去修复它们。它们就存在于人们的代码库中，已经合并，并在生产环境中运行。
我们还发现了许多漏洞，即使是在成熟的代码库中，有时甚至是在有人进行渗透测试之后。
在技术细节方面：
- 我们检查代码库并找出如何为本地开发构建它，并通过测试进行验证。
- 我们对构建的本地开发状态进行快照。（我们使用Runloop对此，并且非常喜欢它。）
- 我们启动数百个本地开发环境的副本，以千种方式测试代码库，并标记出看起来不正常的行为。
- 我们挑选出最显著、最令人担忧的例子，并将其作为线性票据、GitHub问题或电子邮件发送。
在实践中，这个工具运作得相当不错。我们能够在从编译器到交易平台（甚至是Rust代码）等各种项目中发现错误，但最佳效果是在应用后端。
我们的方法在质量和计算之间进行了权衡。我们的代码库扫描需要几个小时，远远超出代码审查机器人所能承受的范围。但结果是我们可以更明智地利用工程师的注意力，我们认为这将是最重要的变量。
从长远来看，我们认为计算成本低，而工程师的注意力成本高。合理使用最新的模型可以在大型代码库中执行复杂的更改。这意味着在软件构建中，限制因素是人类的注意力。工程师仍然需要时间和专注来理解信息，例如现有代码、组织背景和产品需求。这些都是工程师能够准确表达他们想要的内容并胜任审查结果差异所必需的。
目前我们正在发现错误，但我们正在开发的技术也扩展到许多其他背景下的半主动工作，以改善代码库。
欢迎试用并告诉我们你的想法。首次扫描免费，无需信用卡： [https://detail.dev/](https://detail.dev/)
我们也在扫描开源代码库，如果你有任何请求。系统的信噪比相当高，但我们不想冒着自动打开问题而打扰维护者的风险，因此如果你请求扫描开源代码库，结果将直接发送给你个人。 [https://detail.dev/oss](https://detail.dev/oss)