大家好, 这里是 CodeAgent
最近，Python Flask 作者 Armin Ronacher 发布了一篇文章，讨论了他对 Model Context Protocol（MCP）的一些怀疑与转向:
他并不否定 MCP 的探索意义，但明确指出：当前基于 MCP 的推理驱动模式，并不适合构建稳定、可控的大规模智能自动化系统。
相反，他更倾向于把 LLM 用作 "代码生成器"，将自动化逻辑沉淀为可执行、可测试、可验证的脚本，再由程序驱动流程闭环。
里面不仅仅是技术细节的讨论，更是对 Agent 工程架构设计的一些思考。
MCP 的理想与现实
MCP 的设计初衷是让模型根据上下文灵活调用工具，实现动态且 "智能" 的任务执行。这看似优雅——模型根据当前状态推理出下一步操作，并调用对应工具。
但实践中遇到的主要难题包括：
- 上下文依赖过重：每次调用都需大量上下文信息，推理开销极大，且上下文快速膨胀，导致模型效率下降；
- 调试和复用困难：MCP 调用序列动态生成，缺乏静态结构，调试复杂且难以复用；
- 结果不稳定且不可预测：基于推理的连续调用存在随机性，难以保证每次执行结果一致。
因此，尽管 MCP 在某些场景下表现良好，但从长远角度来看，它难以支撑大规模、可验证且可维护的智能自动化系统。
代码生成的优势：一个博客转换的案例
Armin Ronacher 用自己博客格式转换的经历，阐释了代码驱动自动化的价值：
他没有直接让模型"一次性"做文本格式转换，而是让模型执行以下步骤：
- 解析原始 reStructuredText 为抽象语法树（AST）
- 将该 AST 转换为 Markdown 的 AST
- 渲染生成 HTML
- 编写脚本对比新旧 HTML，剔除因系统差异产生的无关差异
- 批量处理数百篇文章
- 让另一模型对生成的代码和脚本进行审核，多轮迭代提升准确性
这体现了“代码作为中介”的理念，极大提升了复用性和可控性。人类可以检查转换逻辑，运行自动化脚本，保证输出结果稳定可靠。相比单纯依赖模型推理，这种模式显著提升了自动化的稳定性和效率。
推理与验证
推理的灵活性不容忽视，但也带来了不可预测性和验证难题。每次调用都需重新推理，结果可能存在细微差异，增加了额外的验证成本。
而代码生成则是另一条更为稳健的路径——生成静态、明确的自动化指令，支持重复执行，无需每次都重新推理，极大降低了验证难度和维护成本。
Armin 的案例表明，结合代码生成与自动化验证机制，能够构建更可靠、高效的自动化流水线。
如何构建可扩展的智能自动化系统
面向未来，智能自动化应重点关注以下几个方面：
- 安全且高效的代码执行环境：自动生成的代码必须在受控沙箱环境中安全执行，防范潜在风险；
- 优化推理策略：如采用 fan-out/fan-in 机制，拆分复杂任务、集中分析结果，减轻模型推理负担；
- 增强代码可读性和解释性：自动为生成代码附加清晰的人类语言注释，降低非技术用户的理解门槛；
- 融合低代码/无代码平台：赋能业务人员参与自动化设计，推动智能自动化更广泛普及。
通过这些措施，智能自动化系统才能实现真正的规模化、可控且高效落地。
Armin Ronacher 的观点为我们提供了很好的反思视角：智能自动化不应被当前 MCP 的局限所束缚。
依赖模型逐步推理的方式虽然直观，却难以满足工业级规模化和稳定性的需求。相反，让大语言模型生成明确且可执行的代码，借助代码驱动自动化流程，并辅以严格验证，才是未来智能自动化的关键路径。
推荐仔细阅读原文:
当然, 作为一名工程师, 也许可以从下面几个角度思考 Armin 这篇文章
- 可维护性与调试性
MCP 工具链基于推理生成，路径不可预测，调试困难；而代码天然具备可读性与可控性，是工程可维护性的基础。
- 自动化的规模能力
推理链每执行一次都需完整上下文和计算资源，难以横向扩展；代码可复用、可并发，适合大规模任务处理。
- 稳定性与错误恢复
推理一旦失败无法断点重试；脚本失败可日志回溯、部分回滚，有助于构建工程级的容错能力。
- 验证机制的可构建性
推理结果难以验证且易变；代码生成后可加入断言、比对、回归测试，构建稳定可靠的验证体系。
也就是说, 越是面向真实工程的自动化系统，越应将不确定性收敛进代码，用结构化逻辑替代一次次推理，才谈得上可维护、可复用和可扩展。
好了, 今天就到这里
欢迎关注我的公众号 CodeAgent
