美伊战争往哪里走？我让 AI Agent 互相查核，然后做判断

本文持续根据最新战况更新事件时间轴与油价数据，最近一次更新日期见上方「最后更新」。

TL;DR — 我想判断美伊战争往哪里走，所以让手上的 AI Agent 互相查核，拿到可查证的双边财务数据。判断：这是一场两个时钟的消耗战，伊朗的破产时钟走得比较快，但美国也被选举、油价与拦截弹库存追着跑。方法（三层分工＋查证指令产生器）与所有来源都在文中。

我今天早上一直用 Grok 追国际新闻。每回答一轮，它旁边就多一排来源：30 sources、42 sources、55 sources……但当我请它把二十几轮对话整理成一份报告，来源栏最后只剩下一行字：

数据来源：公开新闻报道、官方声明、历史案例参考

零链接，零篇名，零日期。刚才还看得到的几百个来源，一个都没有进入最后的报告。

我追这场美伊冲突，不只是想测试 AI。我真正想知道的是：这场战争往哪里走？而要做出判断，前提是手上的情报可以查证。

这篇文章的上半部，拆解三个 Agent 如何分工，以及错误最容易发生在哪个环节；下半部则根据查核过的财务数据，提出我对战争走向的判断。这篇是「AI 与人类秩序」系列的一部分。

三层分工：谁负责什么

先说结论。多 Agent 查核不是把同一个问题丢给几个模型，再取它们答案的交集。真正有效的做法，是把三种性质不同的工作分开：

关键在于，整理与查核必须由不同的角色负责。查核 Agent 不能先读前一层的推理过程，否则它很容易沿着同一套叙事继续走下去。这三层不一定要由三个不同品牌的模型负责。你也可以在同一个 AI 里开三个彼此独立的对话：第一个找资料，第二个整理，第三个只看成品并逐条查核。重点不在用了几个模型，而是三个角色不能混在一起。

第一层：检索，其实比我预期可靠

这次实测的目的，不是证明 Grok 不可靠。例如，Grok 提到新加坡籍货柜轮 Ever Lovely 在 6 月 25 日于阿曼外海遭无人机击中，驾驶台受损，没有造成人员伤亡。这项信息可以在 gCaptain 的完整报道中查到。

至于「伊朗经济损失达 1,440 亿美元，约占战前 GDP 四成」这个看起来很惊人的数字，也不是模型捏造，而是来自 FDD 的估算。几十轮追问下来，船名、伤亡人数与价格大多仍能回到具体来源。至少在这次测试中，检索层的质量比我原先预期得好。

这一层的操作要点：选择具备即时搜索能力的模型，例如 Grok 或 Perplexity，然后持续追问。只问一次，通常只会得到最表层的事件摘要；追问不同立场、数字是否合理、有没有别的解释，数据才会展开。

第二层：整理，也是 AI 最容易犯错的一层

问题出现在我请 Grok 把二十几轮对话整理成报告之后。后面我把这个过程叫做「压缩」。报告的时间轴从这里开始：

6月17日：美伊签署临时停火协议（MOU）

实际上，战争从 2 月 28 日开始，3 月 4 日海峡关闭。4 月曾短暂停火，之后封锁再次升级，直到 6 月 17 日才签署备忘录。Grok 的报告却直接从 6 月 17 日开始，前面将近四个月被压缩成了背景。这也让后面的数字失去脉络。1,440 亿美元是从 2 月 28 日开战后逐步累积的估算，但报告没有交代前面几个月的战事与封锁，读者很难理解这笔损失是如何形成的。报告同样漏掉了备忘录的核心条款，海峡先维持 60 天免费通行、期满再协商管理权，而真正的争议就藏在那句模糊的文字里。

比漏东西更值得注意的，是原本的保留语气如何在整理过程中消失。对话里我问 Grok 谁先破坏停火，它说：

简单说，先开第一枪的是伊朗，这是美国和多数西方报道的共识。

这句话标了立场，也标了立场的来源范围。我追问伊朗那边怎么说，它照实给了革命卫队的版本。然后我请它整理成报告。第五节变这样：

结论：伊朗先开第一枪，是停火协议破坏的始作俑者。

「这是美国和多数西方报道的共识」消失了，「始作俑者」却进来了。而这件事实际上有争议：7 月 8 日伊朗外交部反过来指控美方破坏协议。我们常把 AI 幻觉理解成模型凭空捏造信息，但这次遇到的不是捏造，而是条件消失了：一句带有立场、范围与保留的话，被压缩成一句确定的结论。 原始数据是真的，但整理过程把原本的保留语气拿掉了。这类错误比捏造更难察觉：捏造通常找不到来源，容易引起警觉；保留语气消失后，事件本身仍然查得到，读者反而可能直接放行。

接着，我把 Grok 的报告交给 Perplexity 重新整理。它补回了不少重要骨架：完整时间轴、60 天免费通行条款、Bruegel 对通行费实际负担者的分析、UNCLOS 的法律争议，以及 IEA 对替代管线容量的估算。更重要的是，这些内容都附有可追溯的链接。Perplexity 也发现，Grok 对通行费年收入的估算低了将近五倍。

最后，我把前两份资料交给 Claude，请它整理成文章初稿。它也错了，而且错了三次。初稿指出 Perplexity 有两处错误，逐一查核后，两项指控都不成立。第一项不是数字错，而是日期消失了。Perplexity 写「布伦特已上涨逾 45%，约增加 35 至 40 美元」，Claude 认为它把先前高峰误写成当前价格。回到来源后才发现，这是 Bruegel 4 月 8 日原文中的数字；真正的问题，是 Perplexity 没有保留数据日期。初稿又说 Perplexity 的「8 月 21 日到期」查不到依据；但那个日期查得到，OFAC 在 6 月 22 日发出 General License X，授权伊朗石油销售 60 天到 8 月 21 日。Perplexity 只是把两个都真实、起算点却不同的 60 天期限接在了一起。

第三个问题更直接。初稿在下方图表中，把 7 月 7 日的油价标成「约 73 美元」；来源原文写的是 7 月 8 日、76.48 美元。既没有 73 这个数字，日期也差了一天。

三个模型，三种掉法，却指向同一个失效点：整理。当模型把多轮对话与多份来源压缩成一份流畅的报告，数据日期、消息立场、适用范围与保留语气最容易在过程中消失。它们在原文里常只是短短的插入语，对理解可信度却非常重要；但在追求精简与流畅的过程中，往往最先被牺牲。

这一层的操作要点：每次把数据交给下一个 Agent，都要确保三样东西一起被保留下来：来源、时间戳与保留语气。少了任何一项，下一层即使想查，也很难准确回到原文。

这次也改变了我对 Perplexity 的看法。我原本以为 Perplexity 在多 Agent 流程中可以省略，这次测试却让我看见它的价值：即使整理出错，它仍保留来源，让我能追溯到原文。相较之下，Grok 报告中「每日损失 4.3 亿美元」没有附上可追溯来源，我至今仍无法确认它来自哪里。

第三层：查核。四条指令

我第一次读初稿时，一个问题都没有看出来。那份稿子结构完整、语气笃定，读起来太顺，让我差点直接发布。但文章挂的是我的名字，最后为错误负责的也是我。

最后抓到这些问题的，是第四个 Agent。它没读过前面的对话与推理，只拿到成品，扮演独立查核员。它和前面几个模型最大的差别很简单：它真的逐一打开了链接。我给它的指令只有四条，其中真正发挥作用的是第三条。

一、查核层必须独立。 查核 Agent 只能拿到成品，不要先读前面的推理过程，否则它会沿着同一条线继续推论，变成替原稿背书。工具有子代理功能，就另开一个独立 Agent；若只有聊天界面，就开一个全新窗口，只贴成品，不要附上前面的推理过程。

二、只回报问题，不要直接修改。 一边检查一边重写，你就很难知道原稿到底错在哪里、错了几项。先留下完整的问题清单，再由人决定要改什么。

三、实际点开来源，不要只靠记忆重述。 这次能抓到日期与价格的错误，是因为查核 Agent 实际打开了 Bruegel 的 PDF 与 OFAC 公告，逐句比对原文。若只让它依赖既有知识或搜索摘要，这些问题很可能会直接过关。

四、明确告诉它：「找到问题比让我过关重要。」 否则，模型很容易把任务理解成协助你完成文章，而不是尽可能挑出问题。

拿到报告后不要照单全收，依结果分流：

• confirmed：已有可靠来源支持，可以保留。
• corrected：有明确来源证明原文有误，应予修正。
• unverifiable：目前无法确认，可删除、补充来源，或改成较保守的表述。
• overreach：事实本身成立，但推论超过证据能支持的范围，应收窄措辞。

还要多留一道防线：查核 Agent 本身也可能出错。 它回报的每一项「原稿有误」，仍要由人打开来源确认一次。这次那份报告里有一条是它自己的推算，它主动标了「此为我的推算，非查证」。真正该警惕的，是推算被写得像已经查证过的事实。如果使用 Claude Code 或 Cowork，我已把这套流程包成可安装的 skill，安装后只要说「帮我查证」就会执行。若使用一般聊天界面，直接复制上面的指令，也能得到接近的效果。

查核后的战况情报才清楚

完成检索、整理与查核后，这场冲突的时间线与价格变化才逐渐清楚。下面这张图的价格线是 EIA 官方日线，图上只保留已完成查核、能追溯来源的事件节点；点击节点即可查看细节与出处。

市场冲击最剧烈的阶段在 3 月至 4 月：海峡通行大幅受阻，布伦特从约 72 美元一路升至 126。6 月 15 日协议一出，单日一度跌 5.7%。7 月 15 日九月期货结算在 84.95 美元，反映的是市场对「冲突重新升高，但海峡尚未回到完全封锁」的评估。接下来有几个时间点值得观察。MOU 的免费通行期将在 8 月 16 日到期；OFAC 豁免原订持续至 8 月 21 日，但已在 7 月 7 日提前撤销，清仓期只到 7 月 17 日。另一方面，海峡自 7 月 11 日再次关闭，美军也重启封锁。特朗普则在 7 月 14 日放弃了前一天提出的 20% 过境费方案。

这张图不是单一模型一次生成的结果。价格线接的是 EIA 官方现货序列，事件锚点是经过检索、整理与查核后留下来的版本。它最重要的价值没有变：每个事件都能回到具体来源，而价格这一层，现在整条线就是来源。

所以，这场战争往哪里走？

基于目前可查证的财务数据，这是一场经济消耗战，也是两个时钟的赛跑。伊朗的时钟走得较快，但美国的时钟同样在倒数。

前面的三层流程不是为了比较哪个 AI 更强，而是为了取得足以支撑判断的数字。

伊朗这边的账。 开战前伊朗每天出口略高于 210 万桶原油，5 月一度掉到接近零；FDD 估计封锁期间日损约 4.35 亿美元，开战以来总损失约 1,440 亿，接近战前 GDP 的四成，而且作者明说这是地板不是天花板。官方统计的通胀点对点到了 88.6%，肉类接近 178%；里亚尔一年贬了约五成三。据《华盛顿邮报》报道的 CIA 评估（Iran International 转述），伊朗「至少能撑 3 到 4 个月」；体制内经济学者则认为，封锁一旦超过两三个月，伤害会快速加剧。

停火的 26 天，伊朗抢卖出逾 8,000 万桶原油，进账超过 60 亿美元，短暂替时钟回拨了一点。但 7 月 17 日之后，连这扇合法卖油的窗口也关上了。

〈数船比看油价诚实〉这图要看什么？ 油价是市场的情绪，船数是海峡的事实。油价会被 OPEC、库存、联准会这些跟海峡无关的东西推动；船数不会。两条线分岔的时候，通常是市场在吓自己。

数据从哪抓：IMF PortWatch（IMF × 牛津），卫星 AIS 统计。走它的 ArcGIS 开放端点 Daily_Chokepoints_Data/FeatureServer/0/query，portid=‘chokepoint6’ 就是霍尔木兹。免费、无需 key（2026-07-16 实测）。用 where 条件直接在上游过滤，不抓整份；outFields 只取 date、n_tanker、n_cargo、n_total，油轮与货轮分开，口径不混。

起点设 2026-02-20，开战日前一周。有基准带才看得出跌多深，不然那条线只是一堆数字。

更新频率：每日抓，但数据落后 4 到 7 天。所以这是「每日粒度、非即时」的东西。这个差别必须写进 UI：data_through 记的是数据实际截止日，不是抓取日。写「即时」就是说谎，写「每日更新」也是。诚实的讲法只有「数据截止 X 月 X 日」。

防呆比抓取重要。上游会坏，坏法有很多种：

• MIN_ROWS = 100：2/20 起算至今 140+ 列、只增不减。回传远低于此就是上游截断，直接失败，不写进残缺数据
• exceededTransferLimit：ArcGIS 单次查询有上限，超过就报错要求分页，不会静静漏掉尾巴
• toISODate 同时收 epoch ms 与字符串：ArcGIS 的 date 字段依服务设置回不同类型
• 逐列验 Number.isInteger 且非负：脏数据进不来
• 写 tmp 再 renameSync：atomic，不会有半截文件
• 失败一律非零 exit、不覆盖既有 JSON

提醒：宁可显示旧数据（有标日期），不要显示坏数据。数据没变就完全不动文件，cron 靠 git diff 判断要不要 commit。

还有一个限制，它比延迟严重：AIS 是船自己发的信号，关掉就消失。而伊朗指控 Mombasa 与 Al Bahiyah 的理由，正是「关闭识别系统」。也就是说，冲突越激烈、船越可能关 AIS，这张图就越低估实际流量。

所以它量的不是「多少船通过」，是「多少船一边通过一边公开自己在通过」。是这张图的认识论边界。

当有人说「海峡已经恢复正常」，我们有一条 IMF 的线可以对。

美国这边的账。 官方口径到 6 月底花了约 300 亿美元，CSIS 估 340 到 420 亿，其中弹药 261 亿是最大宗。绝对金额不小，单位交换更难看：一枚拦截弹是无人机造价的几十倍。以 GDP 比例粗略比较，美国目前的直接军费约占 GDP 的 0.15%；伊朗承受的整体经济损失则接近战前 GDP 的四成。两者口径并不完全相同，但仍足以看出承受力的巨大差距。核心不在谁花得少，而是谁更付得起。

伊朗的军费是个黑箱，只能推算。 没有任何智库发表过伊朗方弹药消耗的美元估算，所以这一段是本文的推算，非查证。已知伊朗发射约 1,500 至 2,300 枚弹道导弹（INSS、NBC/IDF 与 JINSA 口径不一），以及约 4,400 至 5,400 架自杀无人机（含代理人发射，依统计口径）。依公开单价区间粗估，作战消耗约为 10 至 50 亿美元，大约是美方直接军费的十分之一。这正是廉价消耗战的设计：用较低成本，迫使对方消耗昂贵拦截弹。

但伊朗还有另一本更大的账：被摧毁的军事资产。FDD 估计其重置成本约 460 亿美元，约占 FDD 总实体重置估算（910 亿）的一半，相当于伊朗 4 到 6 年的年度军费（SIPRI 口径年约 74 亿）。若把弹药消耗与受损军事资产合并计算，两边的军事账单可能落在接近的量级，但性质完全不同：美国消耗的是仍可通过预算与产能补回的现金流；伊朗损失的则是短期内难以重建的资本存量。

不过，美国也有三个自己的时钟。

第一是拦截弹库存。 七周作战用掉近半 Patriot、至少一半 THAAD，2026 年内没有新的 THAAD 交付，补货要等到 2027 年。

第二是期中选举。 58% 民众反对这场战争，汽油从每加仑 2.98 美元涨到 4.48 美元（5 月中），战争账单直接寄到选民家里。

第三是油价的缓冲空间。 战略储油已降到 1983 年以来最低，美国能用来压低油价的政策工具比过去更少。

美国的行为也对得上这三个时钟：四个月内三度寻求停火，7 月 13 日提出的过境费方案一天之内就放弃。

所以我的推论是：美国承受成本的相对能力远高于伊朗，封锁式的经济消耗战对它可行；拖得越久，对伊朗越不利。但时间不是单边站在美国那里。这是伊朗的破产时钟，与美国的选举、油价、拦截弹时钟之间的赛跑，哪一个时钟先响，战争就可能在哪里转弯。

这个判断有一条边界：它建立在 7 月中可查证的公开数据上，而有几个关键数字到今天仍然查不到。伊朗还剩多少可动用的外汇储备、7 月 8 日战事重启后美方的新增支出、伊朗 7 月的通胀，都没有可信数字。任何一个补上，判断就可能要修。这正是上半篇那套方法存在的理由：做出判断不是结束。判断挂在数据上；数据一变，它就必须跟着调整。

需要问的三个问题

除了工具与流程，让查核质量提高的，是我在对话中反复问的三个问题。它们不需要任何付费订阅。我问「伊朗方面怎么说？」它才补上革命卫队的版本；我问「伤亡人数合理吗？」它才检查船员编制与命中位置；我问「有没有可能是自导自演？」它才开始正面检验另一种假设。

整理成最简单的版本，就是三个问题：对面怎么说？这个数字合不合理？它有没有可能不是表面上看到的那样？

这些问题不一定会由模型主动提出。你不追问，它通常就会沿着上一轮形成的叙事继续回答。这三句话就是第一层「持续追问」的内容。

我之前在〈知识管理不靠自律，靠管线〉里写过：凡是长期依赖人类手动维持的流程，最后都很容易崩坏。当时谈的是笔记整理。这次放到事实查核上，我才发现这个结论只说对了一半。管线可以帮你搬运数据、保留来源，甚至自动派一个 Agent 去把链接逐条打开。但是否启动它，最后仍需要有人做决定。

今天我差点没按。

当每个人都能快速整理国际局势，下一个问题是什么？

工具确实已经到位。一个早上跑完三层流程，我拿到的数据量与分析广度，大概接近十年前一名记者要靠数据库、智库与多次采访才做得出来的初步研究。信息取得的门槛已经低得惊人。

但入场门槛，仍然是愿不愿意多问一下：这个数字从哪里来？

多叠几个 AI，不会自动回答这个问题。若每一层都只是重写上一层的结论，错误只会被整理得更流畅、更有结构，也更像一份可以直接寄出去的正式报告。Grok 那份报告的最后一行写着：「本报告仅供参考，不构成投资或决策建议。」它连免责声明都学会了，只是还没学会把来源带着走。

上面的查证工具，是我今天替自己补上的一道防线。以后每篇重要文章，都会先跑一次。你也可以直接拿去使用。

常见问题

Q: 多 Agent 查核要怎么分工？

分成三层。检索层要广度与即时性，用具备网络搜索的模型，把一个问题持续追问而不是问一次就收。整理层把对话收敛成结构，这层最容易出错，交出去时来源、时间戳与保留语气必须一起被保留。查核层必须由独立的 Agent 负责，不能先读前面的推理过程，只拿成品，指令是「只回报、不要改」，并要求它实际打开每个链接回到原文。

Q: 一定要同时订阅三个 AI 吗？

不用。三层不一定要由三个不同品牌的模型负责，你也可以在同一个 AI 里开三个彼此独立的对话：第一个找资料，第二个整理，第三个只看成品并逐条查核。重点不在用了几个模型，而是三个角色不能混在一起。

Q: Grok 那份报告的数字到底哪些是真的？

船名、日期、伤亡数字大多正确：Ever Lovely 6 月 25 日遭无人机击中、Mombasa 与 Al Bahiyah 7 月 13 日遭巡航导弹击中、1 死 8 伤（6 名印度籍、2 名乌克兰籍、4 人重伤），逐条查得到。1,440 亿美元也不是捏造，出自 FDD 估算，但 FDD 给的是 500 至 3,000 亿的范围、1,440 亿只是最可能值，报告写成了确定数字。

Q: 没有付费订阅也能做吗？

可以，成本主要是耐心。单一模型也能跑这套，只是你得自己扮演查核层：开一个全新对话窗口，贴上成品但不要贴你的推理过程，然后照四条指令跑。真正起作用的动作只有两个：追问另一方的说法，以及打开来源自己看一眼。

想自己做一张这种图？把这段丢给 Claude Code 或其他 AI 编码工具

上面霍尔木兹海峡通过船数那张图背后的抓取管线，逻辑可以整段复制给任何一个 AI 编码工具（Claude Code、Codex 之类），换一个你关心的瓶颈或港口即可：

我想做一个「每日通过量」数据管线，数据源是 IMF PortWatch（IMF × 牛津大学，
卫星 AIS 统计）的公开 ArcGIS 端点，不需要 API key。

端点：
https://services9.arcgis.com/weJ1QsnbMYJlCHdG/arcgis/rest/services/Daily_Chokepoints_Data/FeatureServer/0/query

我要看的是「{我关心的海峡/瓶颈名称}」。麻烦先帮我查一下这个图层里
portid 的代码对照表（不要用猜的，去查 IMF PortWatch 官方页面
https://portwatch.imf.org/ 或直接对端点下无 where 条件的查询看
distinct portid 有哪些值，列出来给我核对），再往下做。

抓取规则：
- where 条件直接在上游过滤（portid + date 起算日），不要整份捞回来再筛
- outFields 只取需要的字段（date、船种分类、总数），不要囫囵吞枣
- 起算日设在我关心的事件发生前一周左右，留一段「事件前基准带」，
  不然画出来的线没有对照、看不出异常
- 数据有已知发布时差（PortWatch 大约 4-7 天），这件事要记录成
  data_through 字段（数据实际截止日，不是抓取日），前端文案只能写
  「数据截至 X 月 X 日」，不准写「即时」或单纯「每日更新」

防呆规则（这比抓取逻辑本身更重要）：
1. 设一个 MIN_ROWS 下限（用「起算日到今天预期至少有几列」抓大概值），
   回传列数远低于这个数字就直接视为上游截断，非零 exit，不要把残缺
   数据写进文件
2. 检查回传里有没有 exceededTransferLimit 这种字段，代表这次查询被
   服务端截断了，要嘛报错要嘛做分页，不要让它安静漏尾巴
3. 日期字段要同时处理数字（epoch ms）和字符串两种类型，因为 ArcGIS
   服务不同设置回传格式不一样
4. 每一列的数值都要验证是非负整数，不是就丢错，不让脏数据进来
5. 写文件用「先写暂存文件、成功再 rename 过去」的 atomic write 方式，
   不要直接覆盖原文件，避免程序跑到一半被中断留下半截文件
6. 任何一步失败都是非零 exit、不覆盖既有的正常 JSON。宁可让网站
   显示带着明确日期的旧数据，也不要显示坏数据
7. 如果这次抓到的数据跟上次一模一样，就完全不要动文件，让后续的
   自动化（例如 cron 判断 git diff 有没有变化）可以据此决定要不要
   真的 commit，避免每天产生没有意义的杂音 commit

最后帮我想一下：这个数据本身的「盲点」是什么？（提示：AIS 是船只主动
广播的信号，关掉就消失于数据中，冲突区域越危险，这个方法本身就越可能
低估真实流量。）把这件事讲清楚，不要让看图的人误以为这是「绝对真实
的船只位置」。

这段提示词刻意写成「先查 portid 对照表、不要用猜的」，是因为 chokepoint6 是我们已经实测验证过的霍尔木兹代码，换成别的海峡（马六甲、苏伊士、巴拿马）代码可能不一样，直接照抄容易查错地方，让 AI 先去源头核对比较保险。