别再用工作流捆住AI智能体，给它做「儿童防护」

过去两年，构建 AI 智能体的主流姿势是画流程图：用 LangGraph、n8n 这类工具把每一步拆成节点，用状态机把模型的行为锁死。这套方法看起来可控，但它建立在一个隐含假设上——模型会犯错，所以必须被脚本约束。

Reddit 上一位开发者提出了一个反向思路：与其用刚性工作流捆住推理能力强大的模型，不如给运行环境做「儿童防护」（childproofing）。他为此搭了一个叫 Customer Pulse 的原型并公开了架构取舍。这个思路值得认真拆解，因为它触及了智能体工程中一个根本性的分歧：编排（orchestration）与验证（verification），哪个才是重点。

核心论点：验证优先于编排

原帖作者的核心主张可以概括为三条。

第一，验证优先于编排。 计数、渲染、数据清洗这类必须精确的操作交给代码脚本处理，每一步结束时检查证据，而不是强迫智能体走一条预设的流程图路径。模型负责规划和执行循环，代码负责兜底和验证。

第二，harness 本身就是应用。 让模型自己规划、自己跑执行循环。为当下模型的缺陷硬编码各种 workaround，本质上是在给未来埋技术债——等下一代模型原生绕过这些限制时，你写的补丁全成了负担。

第三，自然语言改变系统行为。 把「用例引擎」和客户的纯英文「profile」拆开，领域专家用几分钟就能调整优先级、路由和行为，不用等工程师改代码重新接线。

这三条指向同一个架构选择：智能体的行为边界由环境约束和结果验证定义，而不是由流程图定义。

Harness 在智能体语境中指的是包裹大模型、负责管理其运行循环的框架层：它接收模型输出的动作意图，执行工具调用，把结果回填给模型，并决定何时终止。与传统工作流引擎不同，harness 不预设步骤顺序，只提供工具、上下文管理和终止条件。文章所说的「harness 本身就是应用」，意即应用逻辑不再散落在流程图的节点里，而是集中在这个运行循环及其配置中，模型负责在循环内自主规划，harness 负责执行与反馈。

原型验证：同一套代码跑两个完全不同场景

为了验证这个思路，作者构建了 Customer Pulse——一个作为完整应用运行的通用 harness。

他配置了两个完全不同的虚构客户场景：一个是 Zendesk 加 BigQuery 的银行客服体系，另一个是处理原始 CSV 的航空公司问卷系统。两个场景跑在完全相同的代码库上，切换配置和调整行为只靠纯英文描述。

这个测试的价值在于它检验了一个关键假设：如果 harness 设计得当，同一套运行时能否通过自然语言 profile 适配差异巨大的业务逻辑。作者的结论是肯定的，同时也坦承了代价——token 消耗、延迟、以及沙箱安全方面的真实 trade-off 都在他的深度长文里做了说明。

换句话说，这套方案不是免费的。放弃刚性工作流换来了灵活性，但付出了推理成本和工程复杂度。

为什么刚性工作流是个陷阱

理解这个观点的价值，需要看清当前工作流范式的三个问题。

模型能力在涨，workaround 在贬值。 每当你为「模型不会做 X」写一段硬编码逻辑，你其实是在赌这个缺陷会长期存在。推理模型的迭代速度远超大多数团队的发布周期，去年必须靠状态机兜底的环节，今年可能一句提示就能稳定完成。硬编码的约束不会自动消失，它们会变成没人敢删的遗留代码。

流程图假设了错误的不变量。 状态机擅长处理步骤确定、分支有限的流程。但真实业务里的判断往往是模糊的——优先级怎么排、这条信息该路由给谁、什么算「足够好的证据」。把这些判断塞进节点和边，等于用工程结构的刚性去逼近业务语义的柔性，中间必然产生大量例外处理。

领域专家被挡在系统之外。 在纯代码编排的方案里，调整行为意味着改代码、测试、部署。而真正懂业务优先级的人通常是运营或领域专家，不是工程师。把行为定义翻译成纯英文 profile，缩短的是从业务意图到系统行为的反馈回路。

Workaround 在这里特指为弥补模型当前能力缺口而写的硬编码补丁，例如强制模型在某个节点输出固定格式、检测到特定关键词就跳转分支、或在提示词里反复强调「不要做某件事」。这类补丁的共同特征是绑定当下模型的缺陷而非业务本质。它们的隐性成本在于：补丁越多，系统行为越依赖提示词与代码的脆弱耦合；当模型升级后，补丁往往不会被主动清理，反而成为难以判断是否仍必要的遗留逻辑，抬高了后续修改的认知负担。

Evals（评估集） 指用于系统性衡量智能体输出质量的测试集合，通常由输入样本和判定标准组成，判定方式可以是精确匹配、规则校验或模型评分（LLM-as-judge）。在验证优先的架构中，evals 承担了原先由流程图节点承担的正确性保证职责，因此其覆盖度和判定标准的严谨程度直接决定了系统可靠性。挑战在于开放性任务缺乏唯一正确答案，需要设计分层判定标准，并持续用真实失败案例反哺评估集，这本身就是一项需要长期投入的工程。

真实代价：别忽略 trade-off

这套思路听起来优雅，但作者自己也没有回避它的成本，这恰恰是讨论值得参考的地方。

Token 与延迟。 让模型自己规划执行循环，意味着更多的推理步数和更长的上下文。相比走固定路径的工作流，每一步都可能产生额外的模型调用开销。对延迟敏感的场景，这是硬约束。

沙箱安全。 「儿童防护」的关键在于环境边界必须是真的硬边界——文件系统、网络访问、数据写入都要被真正限制住。如果边界只是提示词里的君子协定，那整个架构的安全性就无从谈起。作者明确把沙箱安全列为一个需要认真对待的 trade-off，而不是顺手带过的细节。

评估体系的前提。 测试驱动的 evals 要求你能定义什么叫「做对了」。这在计数、格式、数据完整性上容易，但在开放性判断上很难。验证优先的架构把复杂度从「编排」转移到了「评估」，后者并不比前者简单。

沙箱（sandbox） 是操作系统或容器层面的隔离执行环境，通过命名空间、权限控制、资源配额等机制限制进程能访问的文件、网络和系统调用。在智能体场景中，沙箱区别于「提示词约束」的关键在于它是强制性边界：即使模型被诱导或产生幻觉去执行危险操作，沙箱也会在内核或运行时层面拒绝。要让「儿童防护」成立，代码执行、文件读写、外部 API 调用都必须落在沙箱内，并配合最小权限原则，否则所谓环境约束就退化为一种可以被模型绕过的软性建议。

这对智能体工程意味着什么

抛开原型的完成度，这个讨论指出了一个正在发生的转向：智能体工程的重心，正在从「怎么把步骤串起来」转向「怎么定义边界和验证结果」。

如果模型能力持续增强，那么长期来看，最有价值的工程投入不是写出更精密的流程图，而是构建更可靠的执行环境、更严格的代码级验证、以及更能反映真实业务目标的评估集。前者会随模型迭代贬值，后者会持续增值。

作者在帖子里自嘲说「尽管用了这么多儿童防护的比喻，我并不是家长」，并邀请大家拆解他的架构。这个邀请本身值得回应：刚性工作流不是错的，它在模型能力不足、流程高度确定的场景里依然有效。真正的问题是，当模型已经能自己推理时，我们是否还在用约束弱模型的方式去使用强模型。

答案可能因场景而异，但至少值得每个构建智能体的人重新问一遍：我写的这段流程，是在放大模型的能力，还是在替模型做它已经能做的事？