一、从一句话说起

最近看到一段关于 Claude Code 架构的讨论，里面有一句话让我印象深刻：传统 Agent 是"流程决定应用上限"，而 Claude Code 是"大模型上限决定应用上限"。

这看似是在讲 AI 应用的架构模式，但仔细想想，它戳中的是一个更普遍的问题：企业内部项目，到底要不要用流程去限制？权限管控做到什么粒度？面对不同业务，又该怎么选择架构？

而最近很火的 Harness 工程和 Loop 工程，恰好给这个讨论提供了一个绝佳的切入点。这篇文章不聊代码实现，只聊背后的设计思想。

二、两种范式的本质：流水线 vs 自组织团队

要理解这个问题，先得看清两种架构范式的根本差异。

传统模式像流水线。 每个岗位各司其职，不需要动脑筋，按流程走就行。好处是确定性强、可复制、对人员能力要求低。坏处也很明显：上限被流程本身锁死了。流水线上每个工位招博士还是本科生，区别不大，因为工位的技术含量本身就不高。流程一旦定下来，能力再强的人也只能在框架里打转。

传统 Agent 的架构也是这个逻辑：框架先定义好一条完整的流程–规划、执行、检查，每个节点是预定义的。模型只是在每个节点上做"填空"。如果执行节点出了问题，它自己不能决策，必须层层上报给规划者，规划者重新编排流程，再重新执行。代码会变得非常臃肿，大量业务逻辑堆积在规划者环节，异常处理比正常逻辑还多。

Claude Code 模式像自组织团队。 老板只发指令，不规定怎么干。每个部门自己规划、自己执行、自己检查。上限不再由流程决定，而由团队（模型）的能力决定。团队从本科生升级为硕士，产出立刻翻倍，流程一行都不用改。

这两种模式的差异，本质上是对"确定性"和"灵活性"的取舍。没有哪种是绝对正确的。真正的问题不是"要不要流程"，而是"你这个业务，到底需要多少确定性"。

三、Harness 与 Loop：大模型决定上限的工程化表达

理解了两种范式的差异，再来看最近很火的 Harness 工程和 Loop 工程，就会发现它们不是什么新概念，而是"大模型决定上限"这一思想的工程化落地。

Harness 工程：做一层极简的壳

Harness 的核心思想是：不要给大模型套复杂的多 Agent 编排框架，而是只搭一个极简的执行外壳（harness），把工具、上下文、权限边界定义好，然后让模型自己驱动整个流程。

Claude Code 本身就是一个典型的 harness–一个命令行环境、一套文件读写工具、一个 bash 权限口子，剩下的全靠模型自己判断。它没有预定义"先规划再执行再检查"的流程，模型自己在每一轮决定下一步干什么。

和传统 Agent 的对比非常直接：传统 Agent 是框架定义流程，模型填空；Harness 是框架几乎不存在，模型说了算。一个重框架轻模型，一个轻框架重模型。

Loop 工程：把控制权交还给模型

Loop 指的是 agentic loop（智能体循环）：模型思考 -> 调用工具 -> 观察结果 -> 再思考 -> 再调用……直到模型自己认为任务完成。

这和传统 Agent 的"流水线"是两个物种。传统模式是一条有向无环图（DAG）：A 做完交给 B，B 做完交给 C，路径是预定义的。Loop 模式是一个 while 循环：每一步该干什么，由模型在当前上下文里自己决定。出了问题，模型自己看到结果、自己纠偏，不需要外部规划者介入。

所以 Loop 的本质是：流程不再是预先设计的，而是在循环中动态涌现的。 控制权从框架交还给了模型。

一个关键区分：Harness 做的是"地板工程"

Harness 和 Loop 虽然属于"大模型决定上限"的阵营，但并不意味着零约束。恰恰相反，好的 harness 设计恰恰印证了那个判断：

• 权限管控是地板：harness 必须把"能做什么、不能做什么"定义清楚。Claude Code 放开读取权限、收紧写入删除权限，这就是 harness 层面的安全地板。
• 业务流程是天花板：harness 不规定模型"怎么做"，只规定"能碰什么"。loop 的每一步走什么路径，完全由模型决定。

换句话说，harness/loop 工程做的是"地板工程"，而不是"天花板工程"。 它把确定性投资在安全边界上，把灵活性全部留给模型。

四、企业内部项目到底要不要限流程？

理解了 harness 的思路，再回到企业内部项目的问题，答案就清晰了。

先说结论：权限管控是底线，流程是手段，不是目的。

很多企业内部项目的设计思路是"先定流程，再填人"。把所有路径都想清楚，每个节点定义好输入输出，异常分支覆盖到极致。初衷是好的–规避风险、保证质量。但实际效果往往走向反面：业务逻辑还没写完，异常处理的代码量已经超过了正常流程；流程稍有变动，整个链条都要改；团队花了大量精力维护流程本身，而不是交付业务价值。

这就是"流程决定上限"在企业项目中的真实写照：你用流程防住了风险，也用流程锁死了可能性。

但这不意味着应该完全放权。企业内部项目和开源项目、个人项目有本质区别：

1. 合规要求是硬约束。 财务系统、审批系统、数据访问，权限管控不是"要不要"的问题，是"必须做"的问题。
2. 错误成本不对等。 个人项目写错了改一行代码的事，企业内部项目可能是数据泄露、资金损失、合规事故。
3. 人员流动是常态。 流程的一部分价值在于"知识沉淀"，让系统不依赖于某个人的脑中理解。

所以更合理的思路是：把权限管控和业务流程分开看。 权限管控是地板，必须扎实但不需要花哨。业务流程是天花板，应该根据业务特性来调整。一句话：权限管控要严，业务流程要轻。

五、不同业务，不同架构

架构选择不应该有统一答案，而应该看业务落在"确定性-灵活性"频谱的哪个位置。

高频重复型业务（审批流、报销、工单）：偏流程驱动。 路径固定、变体有限、容错率低。流程引擎、状态机是合适的选择。流程在这里不是限制，而是业务本身的表达方式。

探索分析型业务（数据看板、BI、风控策略）：偏能力驱动。 需求多变、路径不确定。更好的做法是提供足够强的基础能力，让使用者自己组合。

混合型业务（大多数企业内部项目）：分层架构。 核心交易路径用流程驱动保证确定性，边缘扩展能力用能力驱动保证灵活性。让架构的重量分配和业务的不确定性分布对齐。

AI 增强型业务（智能客服、辅助决策）：以能力为核心。 定义清晰的输入输出契约和边界条件，中间的推理过程交给模型自主完成。你管控的是"能做什么"和"不能做什么"，而不是"怎么做"。

六、当 Harness 退化成传统 Agent

这是最需要警惕的部分。

Harness 工程虽然属于"大模型决定上限"的阵营，但如果设计不当，它会悄悄退化回传统 Agent 模式。而且这种退化往往是无声无息的–你不会收到一个报错告诉你"你的 harness 已经变成传统 Agent 了"，它只是在迭代中一点一点变重，直到有一天你发现模型的能力被框架限制得死死的。

三种典型的退化路径：

退化一：工具定义过细。

不给模型一个通用的执行入口，而是定义了几百个狭窄的专用命令，每个命令只能做一件极小的事。表面上你是在"做 harness"，实际上你把流程藏进了工具定义里。模型不再是自主选择路径，而是在你预设的工具集合里做选择题。工具越多、越细，模型的自由度就越低，harness 就越接近一条流水线。

Claude Code 的做法值得借鉴：直接给 bash 权限，读取放开、写入收紧。它没有定义"读文件工具"“写文件工具”“搜索文件工具”"创建目录工具"这种细粒度的东西，而是给了一个通用入口，让模型自己组合。工具的粒度，就是流程的粒度。工具越粗，模型越自由；工具越细，流程越重。

退化二：Loop 里塞固定步骤。

表面上是 loop，实际上每次循环内部都强制要求"先做 A 再做 B 再做 C"。比如强制每轮必须先做意图识别、再做工具选择、再做结果校验。这不叫 loop，这叫在 while 循环里套了一条流水线。

真正的 loop 应该是：模型在当前上下文里自己决定下一步干什么。有时候它可能连续调三次工具都不检查，有时候它可能一步都不调直接给出答案。如果 loop 的每轮迭代都有固定的内部流程，那它就只是穿了 loop 外衣的 DAG。

退化三：过度拦截和校验。

模型每次调用工具都要经过重重审批逻辑：先检查权限、再检查参数合法性、再检查业务规则、再检查安全策略、最后还要记日志。每一层单独看都合理，叠在一起就把 harness 变成了一个臃肿的中间层。

模型的能力被框架的校验逻辑稀释。你以为你在做安全管控，实际上你在用校验逻辑重建流程。安全边界应该定义在"能碰什么"这个层面，而不是"怎么碰"这个层面。 管住入口就够了，不要试图管住路径。

退化的共同特征

这三种退化有一个共同特征：harness 从"手段"变成了"目的"。 你不再是在为模型搭一个执行环境，而是在用工具定义、步骤约束、校验逻辑重建那条你以为已经抛弃的流水线。当这个过程完成的时候，你的 harness 就是一个传统 Agent，只是换了个名字。

这和企业内部项目的困境如出一辙。很多团队一开始想做"灵活的系统"，写着写着就开始加审批流程、加参数校验、加固定步骤，最后发现系统比最初想抛弃的那套老流程还重。退化不是一次性的决定，而是一百次"加一点也没关系"的累积。

七、几条设计原则

综合以上讨论，提炼几条可操作的指导原则：

1. 先问"这个业务需要多少确定性"，再决定流程的轻重。 确定性高的用流程，灵活性高的用能力，混合的分层处理。

2. 权限管控作为横切关注点，独立于业务流程存在。 认证、授权、审计是基础设施，不应该和业务流程耦合。用中间件、网关等方式统一处理，而不是在每个业务节点里重复实现。

3. 工具的粒度就是流程的粒度。 给模型粗粒度的通用工具，而不是细粒度的专用命令。管住"能碰什么"，放开"怎么碰"。

4. Loop 就该是 loop。 不要在循环内部塞固定步骤。如果确实需要约束，用约束条件表达（“不能删除生产数据”），而不是用流程编排表达（“必须先检查再执行再校验”）。

5. 渐进式放权。 不要一开始就定死所有流程。先跑起来，观察哪里真的需要约束，哪里可以放开。流程应该是生长出来的，而不是设计出来的。

6. 定期审视是否在退化。 问自己三个问题：工具数量是不是在持续增长？loop 内部是不是出现了固定步骤？校验逻辑是不是比业务逻辑还多？任何一个答案是"是"，退化就已经开始了。

7. 让架构的重量匹配业务的重量。 架构过重和架构过轻一样危险–前者拖死团队，后者埋下隐患。

八、结语

回到开头那句话。"流程决定应用上限"不是在否定流程的价值，而是在提醒我们：当流程从"手段"变成"目的"的时候，它就从地板变成了天花板。

Harness 和 Loop 工程给了我们一个具体的实践框架：做一层极简的壳，把安全边界定义清楚，然后把控制权交给模型。但这条路最危险的地方不在于起点，而在于中途–你的 harness 会在不知不觉中变重，工具越来越多，步骤越来越固定，校验越来越厚，直到有一天它悄悄变回了你最初想要抛弃的那个传统 Agent。

企业内部项目也好，AI 应用也好，真正需要想清楚的是三件事：什么必须管死（权限与合规），什么应该放开（业务流程），以及怎么防止"放开"在迭代中悄悄变成"管死"。

流程是地板，踩稳了才能跑。但别让它变成天花板，挡住你往上走的空间。