代码代理可以完美地编辑一个函数。
但如果你向它提出一个全局性问题——“如果我更改这个，什么会出错？”、“在没有租户检查的情况下，这次写入能否运行？”、“这次迁移是否具有破坏性？”——它往往开始猜测。
有一段时间，我认为答案在于提高令牌效率。现在我认为更深层的问题是：你最初交给代理的事实是什么？
我最近在 Medium 上发表文章指出，只有当你围绕令牌支出重新设计工作——包括验证、上下文和工作流——而不是仅仅购买更多令牌时，令牌支出才会成为一种资产。
这篇文章是从工程角度阐述这一观点。自那以后，我一直在寻找高效的令牌工具，并在没有合适工具时自行开发。接下来是我认为最具杠杆效应的部分：让每个令牌购买一个经过验证的事实，而不是一个猜测。（这只是我个人探索的结果，并非建议。）
令牌效率本质上是一个“你交付什么”的问题
“节省令牌”听起来像是一个关于压缩和缓存的故事——或者最近流行的说法是，给代理提供更多的上下文：更大的窗口、更多的检索。但在我的工作中，真正产生显著影响的并不是更多的上下文，而是我交给代理的那少数几个事实的质量。
代码代理在局部范围内表现强劲。在一个函数、一个差异块内，它们编写得非常出色。但对于全局事实——谁调用了这个、如果我更改它什么会出错、这次写入是否可以在没有租户检查的情况下运行、这次迁移是否具有破坏性——它们往往相当自信地进行猜测，有时还会出错。
因此，我认为有帮助的不是长长的分析日志或全仓库的 grep 搜索，而是简短、准确且有证据支持地交付那些全局事实。令牌效率的核心不在于节省，而在于每个令牌的最大信号量。
你想要的全局事实大多是图结构问题
有趣的是，代理难以处理的大多数全局事实看起来都像图论问题。
- 影响范围 —— 谁依赖于此？→ 调用/引用图上的可达性
- 顺序与循环 —— 这些迁移能否以有效的顺序应用？→ 拓扑排序 + 循环检测（有向无环图）
- “X 在 Y 之前” —— 所需的守卫是否在危险操作之前运行？→ 控制/调用图中的支配关系
- 数据流 —— 不可信的输入能否到达此汇点？→ 数据流图上的可达性
depends-on（依赖于）、calls（调用）、flows-to（流向）、must-precede（必须先于）都是关系，而一组关系构成一个图。一旦你将代理难以自行推导的事实转化为图结构，它们往往就能清晰地呈现出来。
换句话说：这些事实中的每一个都可以用同一种语言来表述——依赖图。影响范围、顺序、守卫支配关系、数据流。这是向代理交付事实的通用语言。
而且，你所需的工具集比你想像的要小：遍历、拓扑排序 + 循环检测、强连通分量、可达性、支配节点，偶尔需要最短路径或最大流算法。除此之外，我认为只要具备识别问题何时是图结构问题的能力，就能覆盖大部分情况。
我想交给代理的事实看起来不像一段文字，而更像这样：
DB.GUARD_BYPASS repo.rs:142 severity=high quality=verified
claim: delete reachable without tenant guard
missing: assert_tenant() does not dominate this sink
path: handler → repo.raw_delete
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
