夜雨聆风这篇文章是我过去三个多月以来，在 AI 生产一线总结的关于人和 AI 的协作框架的认知导论，核心论点就一句话：人与 AI 协作的本质，是在「两种计算」之间分配工作，人只负责提出问题和判断答案。
展开来讲：
脚本：确定性计算——输出确定、可复现、可测试、无幻觉、成本低。 大模型：似真计算——输出「看起来对」，不保证正确、默认采样下不保证可复现、成本较高。 agent：把两者进行组合、能循环能行动的系统。 人：提出问题，定义「什么算对」，同时在没有标准答案处给出自己的判断。
备注：「确定」不等于「正确」——脚本只保证「确定地执行所写规则」；规则写错就「确定性地错」。正确性取决于规则写得对不对，那是人的责任，不是脚本的属性。
我认为这四个要素就是搭建 AI 协作系统的四个必要单位，所谓人与 AI 协作的工程艺术就是：
让确定性计算（脚本）尽量多干，似真计算（大模型）只在非它不可时出手，且在实战中拿到结果以后，立刻让结果回归确定性流程（测试 / schema / 工具执行）。
一、工具的能力边界
人与 AI 协作，涉及到 AI 调用工具、AI 调用自己的能力、人调用 AI 的能力等各个环节，在进入到这个流程的第一步就是要了解各个工具的能力边界，用一张图可以解释清楚：
需要特别澄清的是：
大模型不是「什么都做不了」：它能判断、能生成，纯文本任务（把一段话改写成推文）它自己就完成全部价值，不需要 agent。它缺的是「行动」能力，对接外部世界要靠工具。 大模型「跑完就忘」指的是权重不更新；但只要把历史塞进上下文它就「能想起来」，agent 的「记忆」正是靠这个（记忆不在权重、在上下文）。所以「无状态」和「agent 有记忆」不矛盾：记忆是外挂的上下文，不是模型内化的。
二、三者关系：组合，不是并列
各自的定位：
大模型 = 大脑（判断 / 生成，但碰不到外部世界） 脚本 = 骨架和流程 工具 = 手 agent = 把大脑装进骨架、配上手，让它能循环、有记忆、能行动的那台机器。
最简形态的 agent loop，就是一段脚本在反复调用大模型：
💡 注：这是最简形态。带 planner / critic 分离、搜索回溯、多 agent 协调的架构不止一个 while——协调本身有非平凡开销：扇出、上下文广播、结果聚合、冲突解决。但主干不变：真正「行动」的永远是脚本 / 工具，大模型只贡献每一步的决策。
需要注意的是，agent 不改变底座模型的能力上限。但它能靠推理时计算（inference-time compute）提升实际任务表现：多次采样投票、ReAct 让模型查到事实少幻觉、用工具算数从而算对、多轮自我批评。
所以分清两件事：
能力上限（底座模型潜能）→ 只有换更强的模型才动。 实际任务表现（能把事情做到什么程度）→ 脚手架（agent / 多 agent / 工具）能实打实提升。
注意，我用到的词是「能力上限」和「任务表现」，「agent 没让模型变聪明」这个表达，只在「能力上限」的意义上成立；在「实际表现」上，脚手架是有用的。
至于最近 AI 圈提到的其他热点词：prompt / skill / harness……其实都是在最简形态的 agent loop 这个循环下衍生出来的能力，它们的工作方式如下图：
prompt：步骤①注入 context 的操控文本。在大模型推理的上游（输入侧），只建议、强制不了。它不是工具：工具在②③产生外部副作用，prompt 在①塑造决策，二者在推理的两侧，不能混。 skill：一个「包」（SKILL.md advisory prompt + 可能捆的脚本 / 工具 + 流程），被像工具一样调用，但交付的主要是①的注入内容。它的强制力主要在捆绑的确定性脚本里；SKILL.md 文本那部分仍是 advisory（第五节·乙反模式「Editor 靠自觉遵守 SKILL.md」即此）。所以 skill 在「prompt（料）」和「工具（手）」中间，别整个归进任一格。 工具：步骤②③被调用的「手」。在大模型推理的下游（输出侧），产生外部副作用（读写文件 / 调 API / 取数据）——这才是真正「行动」的地方（也就是文章开头提到的：真正行动的永远是脚本 / 工具）。 harness = ②③④那台自驱循环外壳，就是第一节「脚本」那一档的具体化：循环驱动 + 工具调度 + context 组装 + 笼子（hooks / 权限 / exit-code = 第五节·乙的入口契约 + 预算 + 出口 verifier）。Claude Code 本身就是一个 harness。
两个最容易误解的地方：
harness 不「包含」大模型，是「驱动」大模型；agent 不是 harness 的构件，而是 harness + 大模型 的产物（包含关系别倒）。 人不「驱动」harness：驱动循环的是 harness 自己的确定性代码（发动机），大模型每步决策（方向盘）；人在循环外下任务和审核任务结果。
三、什么时候该用 Agent
第一步，在遇到一个任务的时候，先判断能不能用大模型解决（大模型 vs 纯脚本），也就看这个任务需不需要「语义理解 / 生成」：
不需要（输入和判断都能预先枚举成规则）→ 写脚本。 需要（翻译、改写、语义判断、开放生成）→ 用大模型 ↓。
第二步：用了大模型，要不要做成 agent？（agent vs 单次调用）看是否命中这三个「规则提前写不出来」——命中任一才包成 agent，否则单次调用就够：
四、agent 的代价：用「确定性」换「灵活性」
在日常的生产任务中，并不是所有环节都要用 agent 来解决。脚本的特点是：确定、可复现、可测试、无幻觉、便宜。agent 的长处在于能处理开放性，但每次输出可能不同、会产生幻觉，所以必须有独立的验证环节，这也会导致 agent 的成本会高。
所以在考虑用不用 agent 的时候，真正的问题是：我愿不愿意为处理这份开放性，付出较高的成本，同时「失去确定性」？
没有最好的工具，只有最合适的工具，只有找到合适的任务场景，才能发挥最大的效用。在处理一个长线程任务的时候，往往不是「脚本 or agent」二选一，而是按容器顺序组合（详见第五节）：确定性编排负责顶层控制流，在固定点调 agent，agent 内部再调确定性工具。
五、可靠性藏在组合方式里：强项也是弱点
前面一直在说不同工具的能力边界，一直在强调根据任务场景调用合适的工具。但如果只简单地把前面的内容理解成任务分配，那恭喜你，这两个坑就是为你准备的。
1、强项即死穴：每个执行器的强项，就是它的死穴。
所以可靠架构不是「挑对工具」，是「通过工具的组合让它们互相弥补对方的弱点」：
代码解决 LLM 的漂移 / 不精确（确定性外壳） 独立 verifier 解决 LLM 的自证失败（执行和验证分离，做事的不自评） agent 解决代码处理不了的判断（在代码会脆裂的地方放 agent）
2、编排顺序（最关键）——这是决定你的 agent 系统是一个生产系统，还是工具集的真正分界线：
▎必须是确定性的东西包住不确定性的东西。确定性编排持有控制流，在固定点调用 agent / LLM；不能反过来让 agent 持有控制流去自觉调用代码——那样整条流程的可靠性会被 agent 的「会偏离」污染。
编排结构是一个三明治：
最外层的编排结构必须是确定的，任务流不能随意飘移；agent 可以在指派给它任务的时候自由探索，但始终在一个确定性容器里：限定的入口契约、预算上限、任务结束后的 verifier。agent 持有的是「被关在笼子里的局部控制流」，不是顶层控制流。
六、三层谱系：看起来最复杂的任务最不需要 agent
一个完整 AI 工作流中最多遇到的大部分问题：测试、exit-code、read-before-edit、探头 / 契约 / launchd judge，它们是最强、最便宜、零幻觉的环节，但其实这些环节并不需要Agent来执行。
当你发现自己要靠「更多 agent、更自主」来解决问题，值得先停下来问一句：是这块客观上没有确定性 oracle，还是只是还没去做确定性化？
很多时候是后者（有手段没去用）：那该补脚本，不是加 agent。 但也有时自主性是任务本身开放所必需（订机票要应对未知页面、研究要顺藤摸瓜），这时自主性是力量不是软肋。 所以这是个自检提示，不是「自主 = 没手段」的普遍规律。多 agent 也可能纯为并行加速 / 上下文分治 / 关注点分离而上，不一定是缺 oracle。
七、人在哪：工作流中最核心位置
在这里要区分一下，参与度上的核心与权威上的核心：
人最核心的只有两件事：
定义「什么是对 / 什么是好」：目标 + 成功标准 + oracle 判据的源头。机器能执行判据，定不了判据。 无 oracle 区的终审：审美、品味、战略取舍、高风险决策。死结：没有确定性标准的地方，最后的 verifier 还是人，工程只能降低人当 verifier 的频率，消除不了。
日常调度是人最该避免做的工作，理想的情况是：
开头（定目标）→ ［ 大模型 / 脚本 / agent 自己跑完整条链，带可独立核验的证据 ］→ 关键节点（终审拍板）
八、构建 AI 协作系统之前，完整的决策链路
洛谦 LUMO
