我反复看到的架构翻转：代码不再调用LLM——而是LLM调用代码

我花了很多时间与客户公司打交道。过去几个月，我注意到一些团队构建内部自动化的方式发生了有趣的转变。旧架构很直接：如果公司需要自动化某个内部流程，就会有人构建一个产品。后端、数据库、部署、界面，全套。LLM最初几乎没带来什么改变。团队在原本确定性的管道中加入模型调用，用结构化输出、重试、监控和验证包裹起来，其余架构保持原样。现在我看到一些团队把这个模型反转了。他们不构建专门的应用程序，而是使用：Codex、Claude Code、OpenCode或其他通用代理作为编排器，运行在VPS或用户机器上；一个仓库，包含指令、确定性数据处理脚本，以及到gsheets、email、slack或CRM等系统的连接器；一个定时任务启动代理，或者由人打开它并用自然语言描述任务，而不是通过自定义UI点击操作。有趣的逆转在于：以前，确定性代码是系统，它偶尔调用LLM。现在，代理是系统，它在需要精确性时调用确定性代码。代码不再调用LLM，而是LLM调用代码。为什么这些团队要这样做？ 1. 运行时灵活性：如果某些数据缺失，代理可以查看Gmail、Notion、Jira、CRM或分析工具——前提是它被授予了访问权限。你不需要提前编码所有可能的路径。 2. 变更成本更低：流程变更可能只需要编辑指令文件、更改可用工具或更新小脚本，而不是重建工作流及其UI。 3. 系统可以捕获新的运维知识：如果代理遇到边缘情况并解决它，解决技巧可以被审查并添加到相关指令或技能中。下一次运行会带着更多上下文开始，而不是重新发现同一个问题。 4. 进入门槛低得多：销售、营销和运营人员可以组装自动化，而以前这些需求会在工程积压中搁置数月。他们仍然需要权限、审查和护栏，但不必为每个流程都构建新应用。 这种架构显然不是万能的。 红旗：用户多。共享可变状态。严格的可重复性要求。高执行频率或紧张的延迟要求。稳定契约和已经完全形式化的流程。 绿旗：输入数据经常变化形状。任务需要基于上下文的判断。来源和规则经常变化。目前由人工手动执行，因为“必须看一下情况”。 如果任务像传送带，确定性服务可能仍是正确答案。如果它像操作员或助手的活，代理优先的架构就开始有意义了。以前，自动化一个流程意味着先把它形式化为严格的算法。现在，有些流程可以在仅部分形式化的情况下实现自动化。你在真实系统中看到同样的反转了吗，还是原型一旦进入生产就又会回归传统应用？