Dan Luu 写系统问题时，习惯先测量、再对照、最后才下结论。把「Editing binaries」放到智能体、评测和线上系统里，真正要问的是：默认做法会不会系统性失败。下面用中文整理成可执行的工程笔记，去掉原站导航和无关链接。

问题怎么暴露

Editing binaries is a trick that comes in handy a few times a year. You don't often need to, but when you do, there's no alternative. When I mention patching binaries, I get one of two reactions: complete shock or no reaction at all. As far as I can tell, this is because most people have one of these two models of the world:

There exists source code. Compilers do something to source code to make it runnable. If you change the source code, different things happen. There exists a processor. The processor takes some bits and decodes them to make things happen. If you change the bits, different things happen. If you have the first view, breaking out a hex editor to modify a program is the action of a deranged lunatic. If you have the second view, editing binaries is the most natur

测量时容易踩的坑

For instance, you're forced to do this all the time if you use a non-Intel non-AMD x86 processor . Instead of checking CPUID feature flags, programs will check the CPUID family, model, and stepping to determine features, which results in incorrect behavior on non-standard CPUs. Sometimes you have to do an edit to get the program to use the latest SSE instructions and sometimes you have to do an edit to get the program to run at all. You can try filing a bu

Even if you're running on a mainstream Intel CPU, these tricks are useful when you run into bugs in closed sourced software . And then there are emergencies.

对照之后能下的结论

The other day, a DevOps friend of mine at a mid-sized startup told me about the time they released an internal alpha build externally, which caused their auto-update mechanism to replace everyone's working binary with a buggy experimental version. It only took a minute to figure out what happened. Updates gradually roll out to all users over a couple days, which meant that the bad version had only spread to 1 / (60*24*2) = 0.03% of all users. But they coul

This isn't nearly as hard as it sounds. Let's try an example. If you're going to do this sort of thing regularly, you probably want to use a real disassembler like IDA 2 . But, you can get by with simple tools if you only need to do this every once in a while. I happen to be on a Mac that I don't use for development, so I'm going to use lldb for disassembly and HexFiend to edit this example. Gdb, otool, and objdump also work fine for quick and dirty disass

落到生产里的动作

Here's a toy code snippet, wat-arg.c , that should be easy to binary edit:

#include <stdio.h> int main(int argc, char **argv) { if (argc > 1) { printf("got an arg\n"); } else { printf("no args\n"); } } If we compile this and then launch lldb on the binary and step into main, we can see the following machine code:

值得单独记下的观察

• There exists source code. Compilers do something to source code to make it runnable. If you change the source code, different things happen.
• There exists a processor. The processor takes some bits and decodes them to make things happen. If you change the bits, different things happen.
• If you don't have $1000 to spare, r2 is a nice, free, tool with IDA-like functionality. [return]

落地时建议先做的 5 件事

1. 用自己的真实负载测，而不是只用公开榜或厂商数字。
2. 把评测设计成能抓到失败模式：平均分好看但尾部崩溃，仍然算失败。
3. 智能体默认不会好好用测试；要写进流程，而不是写在口头规范里。
4. 性能和正确性都要有基线，改模型或改语言前后必须能对比。
5. 结论写成可回滚的决策：哪一版配置、哪一版评测集、谁签字。

和智能体产品怎么接

龙虾PRO做 OpenClaw 落地时，同样吃「先测量再扩面」这条纪律：技能、数字员工和网关都要有可复现评测，而不是只看一次演示通过。

本文侧重全链路风控方法论。落地时请用自身业务单据做回放验证，不要把示例阈值直接当生产策略。 相关：风控体检 · 方案资源