OODA 框架由美国空军上校约翰·博伊德提出，原本用于空战格斗。它包含四个步骤：观察（Observe）、判断（Orient）、决策（Decide）、行动（Act），然后不断循环。博伊德发现，谁能更快、更准地跑完这个循环，谁就能在战斗中活下来。
黄仁勋借用这个框架来解释软件的未来：软件不再是写一次跑很久的静态产物，而是一个不断从真实世界获取数据、理解局势、做出选择、执行并再次观察的动态循环。大模型和 GPU 的存在，让这个循环可以跑得极快，从而让软件变得有“适应力”。
黄仁勋说的那个OODA循环，本来是美国空军用来干架的：观察、判断、决策、行动，一圈比一圈快，谁快谁活。 现在他说，这就是软件的未来。意思是写代码、跑模型、上线修bug、调参数，都得按这个打架节奏来。
以后软件不是写出来的，是循环出来的：谁循环得越快越准，谁就是老大。
打仗的OODA循环变成软件公司的活命法则
黄仁勋站在台上说了一句话，软件的未来就是OODA循环。台下的人先是一愣，然后开始鼓掌。
OODA循环本来是打仗用的，美国空军那个叫博伊德的飞行员想出来的。打仗的时候谁反应快谁活，写软件的时候谁反应快谁赢。
老黄的意思是，别再把软件当成一张画完就挂墙上的图纸了，软件是一锅正在冒泡的火锅，你得一直搅，一直看火候，一直往里扔菜。英伟达就是这么干的，他们不搞五年计划，他们搞的是“今天发现不对，今天就把路改了”。这个逻辑听起来简单，做起来要命，因为大部分公司还在搞“写完需求文档才能动键盘”那一套。老黄直接把那套扔进了垃圾桶。
OODA四个字母你记一下：Observe（看一眼发生了什么），Orient（搞明白怎么回事），Decide（决定下一步干啥），Act（动手干）。干完之后再Observe，形成一个圈，转得越快，活得越好。
英伟达的软件团队不搞年度复盘，他们搞的是周复盘甚至日复盘。你问一个工程师这周干啥了，他不会说“我在执行第三季度的计划”，他会说“我发现上周那个方案在客户那边跑不起来，所以我改了个新的”。这就是OODA在干活。
先看这张图里写死的九块东西就是软件以后的样子
上图里写了AGENT、PROMPT、TOOLS&SKILLS、OBSERVE、REASON、ACT、MEMORY、SECURITY&GOVERNANCE、ORCHESTRATION。
你把OODA套上去，立刻就明白了。
OBSERVE就是Observe，REASON就是Orient，ACT还是ACT，中间的PROMPT、TOOLS&SKILLS、MEMORY记忆、ORCHESTRATION协调全部是让这个圈转得更快的零件。
没有这些零件，OODA就是一句口号。有了这些零件，OODA变成了一套能跑起来的系统。
图片里写了一个完整的结构：
从 AGENT=LLM+HARNESS 开始，到 MEMORY 结束。
中间排着 CONTEXT、PROMPT、TOOLS&SKILLS、OBSERVE、REASON、ACT、SECURITY&GOVERNANCE、ORCHESTRATION。
黄仁勋说软件的未来就长这样：不是一行行写死的判断语句，是一个活着的圈-->你先看一眼发生了什么，再想明白怎么回事，然后动手干，干完再回头看。
这个圈转得越快，你的软件就越不怕折腾。英伟达内部早就不写那种“按一下出A、按两下出B”的固定逻辑了，他们把每段代码都包在一个能自己观察、自己改自己的壳子里。用户还没感觉到疼，系统已经把止疼药吃了。
这个壳子就是 AGENT=LLM+HARNESS。AGENT 是跑腿的，LLM 是大脑，HARNESS 是拴狗的绳子。没有 HARNESS，AGENT 会自己瞎跑，比如看到错误率高了就直接把服务器关机。有了 HARNESS，它只能在画好的圈里动。这张图把 AGENT=LLM+HARNESS 写在最顶上，意思是一切从这儿开始。你不是在写一个普通程序，你是在造一个能自己拿主意的智能体。这个智能体不睡觉、不请假、不跟产品经理吵架，唯一的任务就是一遍又一遍跑通剩下的八个格子。
逗逼的是很多人一听说 AGENT 就觉得要写几千行代码。不用。你给 LLM 一段 PROMPT，告诉它“你是运维，你的工作是看 OBSERVE 的数据，然后去 REASON”，它就能干活了。HARNESS 就是几行配置文件，说你最多能动哪几个接口。剩下的全是流程。
老黄那句话的意思就是，以后软件工程的核心不是写 if else，是设计这个圈怎么转。
先给AGENT划定CONTEXT它才知道看哪不看哪
图片里 CONTEXT 写在 PROMPT 上面，OBSERVE 左边。这个位置不是随便画的。CONTEXT 是整个循环的第一道过滤网。AGENT 要 OBSERVE 世界，但世界上有无穷多个信号。
你让它看什么？CONTEXT 就是那个“看什么”的说明书。没有 CONTEXT，AGENT 会把 CPU 温度、办公室湿度、 Twitter 上骂你的人数量全当成信号，然后 REASON 一整天也找不到重点。
CONTEXT 就是给 AGENT 划一个框：“你只管这个框里的事，框外的跟你没关系。”比如你是做推荐系统的，你的 CONTEXT 可以写成“用户点击率、曝光转化率、推荐接口耗时、模型推理延迟”。就这四样。别的比如数据库连接数、服务器风扇转速，统统不在 CONTEXT 里，AGENT 直接忽略。
很多人不理解为什么他们的 AGENT 转圈慢，因为他们在 CONTEXT 里塞了四十个指标，AGENT 每个都要看一遍，转一圈要十分钟。正确的 CONTEXT 应该像机场安检的闸机，只让重要的东西通过。
图里 CONTEXT 紧挨着 PROMPT，因为 PROMPT 是告诉 AGENT 怎么处理 CONTEXT 里的东西。CONTEXT 说“你只管点击率和耗时”，PROMPT 就说“如果点击率掉了超过5%并且耗时涨了超过10%，优先怀疑模型版本变更”。一个定义范围，一个定义规则。没有 CONTEXT，PROMPT 里的规则没法落地，因为 AGENT 不知道从哪取数据。没有 PROMPT，CONTEXT 就是一筐原材料没有菜谱。
逗逼的案例我遇到过。一个团队让 AGENT 做自动扩缩容，他们在 CONTEXT 里写了“CPU使用率、内存使用率、网络流量、磁盘IO、TCP连接数、平均负载、中断次数、上下文切换次数”。整整八个指标。AGENT 每三十秒把所有指标看一遍，REASON 的时候发现有的涨有的跌，完全不知道按哪个决定。后来把 CONTEXT 砍到只剩“CPU使用率”和“请求排队长度”，AGENT 反而判断准了。CONTEXT 不是越多越好，是越准越好。
CONTEXT决定了AGENT用什么尺子量世界
CONTEXT 不只是列一堆指标名字，还要给出每个指标的“正常范围”。你说“关注接口耗时”，那多少算正常？多少算异常？这个不写清楚，AGENT 看到耗时从20ms涨到50ms，它不知道这是正常波动还是故障前兆。CONTEXT 里应该写“P99耗时低于100ms为正常，100ms到200ms为关注，高于200ms为异常”。有了这把尺子，OBSERVE 拿到数据之后可以直接打标签：正常、关注、异常。
这个“正常范围”不是拍脑门定的，是从历史数据里算出来的。你把过去一个月的耗时数据放进 MEMORY，让 REASON 算出一个平均值和标准差，然后 CONTEXT 里写“超过均值加两倍标准差为异常”。这样 CONTEXT 是活的，不是工程师手写的死数字。图里 CONTEXT 在 MEMORY 旁边，就是因为 CONTEXT 可以从 MEMORY 里学。今天算出来的正常范围可能三个月后就不对了，那时候 MEMORY 里的新数据会触发 CONTEXT 的更新。
CONTEXT 还干一件事：定义哪些信号之间有因果关系。比如“推荐接口耗时涨了，通常是因为模型加载慢了”或者“点击率掉了，通常是因为缓存失效了”。你把这种因果关系写在 CONTEXT 里，REASON 的时候就不用从零开始推理，直接沿着你给的因果关系去查。这就像你告诉侦探“凶手大概率是管家”，侦探就重点查管家，而不是把所有人都审一遍。没有这个因果提示，REASON 要试错很多次才能找到真正的根因。
我见过一个很聪明但很蠢的配置：
他们把 CONTEXT 写成了“如果A指标异常，检查B、C、D三个地方”。结果 AGENT 每次都把B、C、D全查一遍，不管A的异常程度有多轻。
正确的写法是“如果A异常超过阈值1，先查B；如果B正常且A仍异常，再查C；如果C也正常，查D”。
这叫带优先级的 CONTEXT。
AGENT 执行的时候按优先级来，大部分情况下查完B就解决了，不需要碰C和D。速度直接翻倍。
用PROMPT把CONTEXT里的范围变成具体指令
PROMPT 在 CONTEXT 下面，它的任务是把 CONTEXT 定义的静态范围翻译成 AGENT 能执行的动态指令。CONTEXT 说“关注P99耗时”，PROMPT 就说“每三十秒去监控系统查一次P99耗时，如果连续三次都高于200ms，触发 REASON 流程”。PROMPT 里要写清楚触发条件、采样频率、动作指令。没有 PROMPT，AGENT 拿到了 CONTEXT 也不知道什么时候该干活。
PROMPT 里还要写 REASON 的推理路径。你说“如果P99耗时高，怀疑数据库慢查询或者缓存命中率低”。这个推理路径就是 PROMPT 的核心。AGENT 按照你给的路径去 REASON，先查慢查询，再查缓存命中率，查到一个符合的就停下。不写推理路径，AGENT 可能会去查CPU、查内存、查网络、查磁盘，把所有可能性都翻一遍。转一圈的时间就从几秒钟变成了几分钟。
图里 PROMPT 连着 TOOLS&SKILLS，因为 PROMPT 里要指定用什么工具去查。你说“查慢查询”，那你要告诉 AGENT 用哪个工具去查。比如“执行 SHOW FULL PROCESSLIST 然后过滤出 Time > 5 的查询”，或者“去慢查询日志文件 /var/log/mysql/slow.log 里读最后一百行”。你不指定工具，AGENT 不知道怎么把“查慢查询”这个指令变成具体的操作。PROMPT 写得越具体，AGENT 跑得越稳。
逗逼的事情我在某大厂见过。
他们写了一个 PROMPT：“如果系统不正常，就修好它。”
就这一句话。AGENT 拿到之后完全不知道该怎么办，因为它不知道什么叫“不正常”，也不知道什么叫“修好”。
正确的 PROMPT 应该像菜谱：第一步干什么，第二步干什么，什么条件下跳转到第三步。
你写“如果P99耗时高于200ms，先查慢查询；如果有慢查询且数量超过10条，加索引并清缓存；如果没有慢查询，再去查缓存命中率；如果命中率低于80%，扩容缓存集群”。
这样 AGENT 拿到手就能干活，不需要猜。
PROMPT 也不是写一次就不改了。你发现 AGENT 老是走错分支，比如明明有慢查询但它先去查了缓存，那你就要改 PROMPT，把“先查慢查询”写得更靠前。
改 PROMPT 本身也是一个 OODA 圈：你 OBSERVE 到 AGENT 的行为不对，REASON 出 PROMPT 顺序有问题，DECIDE 调整顺序，ACT 部署新 PROMPT。这个圈转几次之后，PROMPT 就会变得越来越准。
图里 PROMPT 旁边画了 LLM，意思是你甚至可以让 LLM 帮你优化 PROMPT，自己改自己。
看一眼OBSERVE这一步决定你能不能活下来
OBSERVE不是拿眼睛看，是用传感器看。
在软件世界里，OBSERVE就是埋点、日志、监控、用户反馈、系统报错。你写了一个AI客服，用户问了一百个问题，有三十个回答不上来。如果你不OBSERVE，你就不知道这三十个是啥。过了一个月，用户跑了，你还以为模型挺好的。图里把AGENT放在最前面，意思是OBSERVE这件事可以交给智能体自动做。你不需要派一个工程师每天翻日志，你写一个脚本或者配一个Agent，让它盯着关键指标，温度高了报警，回答不上来的问题自动归类。
逗逼的事情是，很多公司花了几百万搞监控面板，大屏幕挂在墙上花花绿绿的，结果没人看。有一次我去一个创业公司，那个大屏幕上飘着一行红字“错误率23%”，我问他们这个正常吗，他们说“哦那个啊，上周就红了，我们还没看”。这不是OBSERVE，这是摆样子。真正的OBSERVE是观察完了要有东西流到下一步。OBSERVE的结果不交给REASON，就等于没看。
图里OBSERVE下面连着REASON，这很重要。
你看一眼发现温度高了，那REASON就要判断是空调坏了还是服务器过载了。你看一眼发现用户问“你们能退货吗”被AI拒绝了五次，那REASON就要推理是不是知识库里缺了退货政策。没有REASON的OBSERVE就是看热闹，有了REASON的OBSERVE才叫情报。
那张图把OBSERVE放在整个循环的入口，旁边还挂了MEMORY记忆。MEMORY是干什么的？帮你记住上次观察到了啥。如果你不记住，每次都得重新观察，转圈就慢了。比如上周观察到一个规律，周末晚上服务器负载会飙上去，你把这个记在MEMORY里，周五下午就可以提前扩容。没记，周六晚上又崩一次。MEMORY让OBSERVE从一次性动作变成了持续积累的资产。
搞清楚ORIENT靠REASON和MEMORY一起使劲
OBSERVE拿到了原始数据，接下来是ORIENT，图里对应的是REASON。REASON不是瞎猜，是用逻辑把数据变成判断。你观察到错误率23%，REASON就要问几个问题：这个错误是分布在全量请求里还是集中在某个接口？是今天突然涨的还是慢慢涨的？跟最近一次上线有没有时间上的重合？这些问完了，你可能得出结论：“上周四晚上部署的新推荐算法导致老用户请求超时。”这才是ORIENT。
图里REASON上面顶着PROMPT，左边连着MEMORY，右边连着TOOLS&SKILLS。PROMPT怎么理解？如果你在用大模型，PROMPT就是你给模型下的指令，告诉它从哪个角度去REASON。比如你写一个PROMPT：“你是一个运维专家，根据以下日志判断故障原因，优先检查最近24小时内的变更。”这个PROMPT就是REASON的方向盘。没有PROMPT，REASON就像没有地图的导航，乱转。
MEMORY在REASON这一步里扮演的角色更狠。你记得上周发生过类似的错误吗？记得上次是怎么修的吗？如果MEMORY里存了，REASON可以直接说“跟上次问题一样，用那个方案”。这叫经验推理。大部分新手工程师不会这么干，他们喜欢重新造轮子，每次都从零开始。老手上来先翻MEMORY，看一眼历史记录，五分钟出结论。图里把MEMORY画得跟REASON平起平坐，就是这个道理。
TOOLS&SKILLS在这里是REASON的工具箱。你要判断一个数据库慢了，你得会看慢查询日志，这叫SKILL；你得有一个慢查询分析工具，这叫TOOL。没有这些，REASON就只能拍脑门。英伟达的工程师为什么转圈快？因为他们每个人都有现成的工具链，按一个按钮就能看到性能瓶颈。大多数公司相反，工程师要花半天时间去申请权限、装软件、查文档，等工具到手了，黄花菜都凉了。
REASON结束的时候，你必须得到一个明确的结论：“问题出在A，原因是B，解决方法是C。”如果结论是“可能A也可能B”，那你还没完成ORIENT。图里的整个结构都在逼你做一件事——不要把模糊带到下一步。
做决定DECIDE要快而且要敢
DECIDE在图里没有单独写出来，它藏在ORCHESTRATION和ACT之间。你REASON完了，知道了问题在哪，接下来要决定怎么干。这个决定有两个特点：第一要快，第二要敢。快的意思是不要开会讨论两周，敢的意思是不要怕决定错。OODA循环的核心优势就是你可以快速试错，决定错了没关系，下一个圈马上就能改过来。
很多公司的决策流程是这样的：工程师发现问题，写报告给组长，组长给经理，经理给总监，总监开周会讨论，下周再给CTO批，CTO批完再传回来。一个圈转一个月。英伟达怎么做的？老黄说每个人都是决策者，前提是你有足够的信息。图里AGENT+LLM+HARNESS这一层就是干这个的，让智能体或者一线工程师在权限范围内自己决定。你观察到了、推理完了，如果修复方案成本低、风险可控，那就直接ACT，不需要等三层审批。
但你也不能乱决定。图里SECURITY&GOVERNANCE就是管这个的。它不是一个卡你的部门，它是一套规则，告诉你哪些决定可以自己做，哪些必须上报。比如“换个配置参数”这种可以自己决定，“删数据库”这种必须上报。把规则定清楚之后，大部分决定都能在几秒钟内完成。没有GOVERNANCE，要么乱成一锅粥，要么啥都不敢动。
DECIDE这一步的输出是一个明确的指令：“重启实例A”或者“回滚上周四的部署”或者“给知识库加一条退货政策”。这个指令要直接能被ACT执行，中间不要再加翻译层。图里的ORCHESTRATION就是负责把指令编排成可执行的步骤，比如“重启实例A”可能需要先切流量、再重启、再切回来，ORCHESTRATION把这些步骤串起来，ACT只管照着跑。
动手ACT之后立刻回到OBSERVE闭环就完成了
ACT是最容易被骗的一步。很多人觉得ACT就是“我干了”，干完了就完了。不对，ACT之后必须立刻回到OBSERVE。你重启了实例A，然后呢？你得再看一眼错误率降了没有。降了，说明你REASON对了。没降，说明你REASON错了，赶紧再转一圈。
图里ACT在最下面，但它画了一个箭头回到OBSERVE，这个箭头是整个图的灵魂。没有这个箭头，OODA就是一根断掉的链条。有公司花了大价钱搞了自动化运维，ACT完全自动执行，结果自动重启、自动回滚、自动扩容，但就是不自动验证结果。机器重启完了，它不检查服务是不是真的恢复了，然后就下班了。用户还卡着呢，它还以为自己干完了。
逗逼的场景我见过太多了。一个工程师半夜被报警吵醒，他ACT了一下，改了配置，然后回去睡觉了。第二天早上发现配置改错了，整个服务挂了四小时。他缺什么？缺ACT之后的OBSERVE。他改完应该等五分钟，看一眼监控，确认没问题了再睡。这就是OODA转得不够快，只转了半圈。
ACT还有一个容易被忽略的点：ACT的结果要写回MEMORY。你改了啥，为什么改，改完之后效果怎么样，全部记下来。下次REASON的时候可以直接拿出来用。图里MEMORY画在正中间，周围全是箭头指向它，这说明MEMORY不是附件，是核心。没有MEMORY，每一次OODA都是从零开始，永远长不大。有MEMORY，你的系统会越转越快，因为经验在积累。
英伟达的驱动团队就是这么干的。每次发布新驱动，他们先在小范围用户里ACT，然后立刻OBSERVE帧率、稳定性、兼容性，发现问题就REASON，然后DECIDE要不要改，再ACT，再OBSERVE。一个圈可能只要几个小时。等圈转到第五次的时候，MEMORY里已经存了四种失败方案和一种成功方案，下一次类似问题出现，直接从MEMORY里读答案，连REASON都省了。
用PROMPT和TOOLS把OODA转得比对手快十倍
图里PROMPT写在LLM旁边，LLM又连着HARNESS和AGENT。这一块是给OODA装涡轮增压的。以前OBSERVE要靠人看日志，REASON要靠人翻文档，DECIDE要靠人拍脑门，ACT要靠人敲键盘。现在有了大语言模型和智能体，你可以让它们帮你干。
写一个PROMPT：“每十分钟观察一次API错误率，如果超过5%，就REASON可能的原因，列出TOP3，然后DECIDE要不要回滚上一次部署，如果决定回滚就ACT，ACT之后再观察五分钟，把整个过程写回MEMORY。”把这个PROMPT喂给一个AGENT，AGENT就会自动转OODA圈，你不用管。HARNESS是拴住AGENT的缰绳，防止它乱来，比如限制它只能在预生产环境ACT，不能动生产环境。
这就是老黄说的“软件的未来”。
未来的软件不是写死的逻辑，而是一套能自己OBSERVE、自己REASON、自己DECIDE、自己ACT的系统。
你只需要给PROMPT，给TOOLS，给MEMORY，给安全边界，剩下的它自己转。
英伟达内部已经在用这套东西了。他们的自动驾驶软件每天在路上跑，遇到没见过的场景，系统自己OBSERVE到异常，REASON出“可能是个没标注的障碍物”，DECIDE减速绕行，ACT之后继续OBSERVE，整个过程几十毫秒。如果等工程师来决策，车早撞了。
TOOLS&SKILLS在这里也很关键。AGENT不能只靠推理，它得有工具。图里TOOLS&SKILLS单独列了一块，意思是你得给智能体配扳手。比如查日志的工具、跑测试的工具、发邮件的工具、改配置的工具。没有工具，AGENT只能REASON但ACT不了，那就白搭。你给一个AGENT说“如果错误率高就重启”，但不给它重启的权限和工具，它只能干瞪眼。
还有个点容易被忽略：PROMPT本身也要迭代。你发现AGENT老是REASON错，不是AGENT傻，是你PROMPT没写清楚。改PROMPT，写得更精确，加上“优先检查最近一小时内变更的模块”，然后AGENT就变聪明了。这个改PROMPT的动作本身也是一个OODA圈，你OBSERVE到AGENT犯错，REASON出PROMPT不够好，DECIDE改PROMPT，ACT把新PROMPT部署上去。转一圈，AGENT又升了一级。
靠MEMORY让圈越转越快直到对手看不见尾灯
MEMORY是整个图的中央处理器。你看图里MEMORY在正中间，OBSERVE的东西要存进MEMORY，REASON的结论要存进MEMORY，ACT的结果要存进MEMORY，甚至PROMPT的历史版本也要存进MEMORY。MEMORY不是数据库，它是经验库。存什么？存你之前转圈的时候踩过的坑、总结的规律、验证过的方案。
举个例子。你第一次遇到数据库连接池爆满的问题，你用了一个小时REASON出来是因为慢查询太多，然后你DECIDE加索引，ACT加了索引，OBSERVE确认问题解决。你把这三句话写进MEMORY：“症状：连接池爆满；原因：某条SQL缺索引；方案：加索引。”第二次又爆满，你REASON的时候MEMORY直接把这个记录翻出来，你花三十秒就判断出来是不是同一个原因。如果是，直接ACT。不是，再REASON新的。
这就是为什么英伟达的团队迭代速度快得吓人。他们的MEMORY不是个人的，是团队的。每个人遇到的问题、解决的方案全部写进共享的MEMORY系统。新来的工程师遇到问题，先去MEMORY里搜，大概率搜到现成答案。老黄说的“软件的未来”有一半就是指这个——软件系统要有长期记忆，不能每次启动都失忆。
图里SECURITY&GOVERNANCE也跟MEMORY有关系。你不能啥都往MEMORY里存，密码不能存，个人隐私不能存，错误的推理结果不能当真理存。GOVERNANCE定义什么样的信息可以进MEMORY，存多久，谁有权看。没有GOVERNANCE的MEMORY就是垃圾堆，塞满了噪音，真正的信号反而找不到。
ORCHESTRATION在这里的作用是把MEMORY里的经验变成标准流程。你发现某个问题已经被解决了五次，每次都走同一个步骤，ORCHESTRATION就把这个步骤做成一个自动化模板。下次OBSERVE到同样症状，ORCHESTRATION直接触发这个模板，不需要人工REASON和DECIDE，直接ACT。这就从“人转圈”升级到了“系统自动转圈”，速度又上了一个台阶。
你再看那张图，名字叫AGENT=LLM+HARNESS，意思是整个架构的核心是一个被LLM驱动又被HARNESS约束的智能体。这个智能体不睡觉，不放假，二十四小时转OODA圈。
人类只需要做两件事：
第一，写清楚PROMPT；
第二，把TOOLS配好。
剩下的交给智能体。
打仗的法则变成软件的命根子！这就是黄仁勋说的软件的未来，也是英伟达能在AI时代甩开所有对手的原因——他们不是靠一个天才算法赢的，是靠一套比所有人都转得快的OODA循环赢的。