ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">现在我们已经知道了标准化的可行性。但这自然引出了一个更深层的问题：ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">标准化，真的有必要吗？我们是不是在重复造轮子？ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;padding-left: 8px;color: rgb(63, 63, 63);">有效扩大模型的能力边界，让Agent成为可能ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">大语言模型本身是一个大脑，它没有“手”与物理世界或复杂的数字系统直接交互。没有外部工具和标准化的接口，LLM 很大程度上只能停留在“聊天机器人”的层面。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);">要实现更强大的 Agent 功能（即能自主规划并执行任务的 AI），模型需要与外部世界互动。目前常见的方式有：ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;color: rgb(63, 63, 63);" class="list-paddingleft-1">ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;text-indent: -1em;display: block;margin: 0.2em 8px;color: rgb(63, 63, 63);">•ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">模拟人类操作：如 Anthropic 的 Computer Use 功能，模型通过“看”屏幕并模拟键鼠来操作软件。这种方式潜力很大，但实现并不稳定。ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;text-indent: -1em;display: block;margin: 0.2em 8px;color: rgb(63, 63, 63);">•ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(15, 76, 129);">调用专用工具/API：这是目前更主流的方式。例如，要让模型浏览网页，可能需要像智谱 AutoGLM 那样调用 WebGLM 插件。问题在于，在 MCP 这样的开放标准出现之前，各大厂商的 Function Call / Tool Use 功能往往是私有协议，只能绑定自家模型，工具生态也受限。这极大地限制了通用 Agent 的发展和跨平台协作的效率。一个开放的、标准化的协议（如 MCP）则有望打破这些壁垒，让任何模型都能方便、统一地调用各种外部能力。大幅提升 AI 工作流的稳定性与可靠性
LLM 的一个固有特性是其输出具有一定的随机性。即使我们用提示词工程技巧限制、调整温度系数，也很难保证模型每次都输出完全一致且格式绝对精确的结果。
这在简单对话中或许问题不大，但在以下场景中则可能是致命的：
- •多 Agent 协作：一个 Agent 输出的微小偏差，可能在后续传递中被放大，导致整个任务链失败。
- •与程序代码交互：很多外部系统（如 API、数据库）对输入的格式要求极为严格。模型输出如果稍有偏差（比如 JSON 格式错误、参数名微小变动），就可能导致程序调用失败甚至崩溃。
使用定义好的 JSON 结构进行数据交换，就像给模型输出加了一道强制限制。 它确保了无论模型内部如何“思考”，最终与其他模块或系统交互时，都能遵循统一、可靠的格式规范，从而显著提升整个 AI 应用或工作流的稳定性和可靠性。(关于这一点，我后续会专门写文章探讨如何提升模型输出稳定性的具体方法)
提升了AI产品的开发效率
当输入、处理、输出模块都遵循标准接口（如统一使用 JSON 交互）模块化后，每一部分的实现逻辑是相互独立的。开发者可以将精力聚焦在核心业务逻辑（主要是 Prompt 设计和模型选择）上。想换个大模型？只需替换“处理”模块，无需改动前后端任何代码。想增加一种输出格式？添加一个符合标准的“输出”模块即可，前面两个阶段都不需要任何变动。
在内部的“万能库”实践中，这种模式平均能节省约 70% 的 AI 功能开发和实验时间。
提升模型的使用性能，避免重复制造垃圾
没错，可以提升模型性能。
最近很流行“Vibe Coding”的概念（用 AI 辅助编程），但让 AI 从零开始构建整个应用（尤其是涉及前后端分离、微服务等复杂架构时）往往容易“翻车”。我用 Cursor+Claude 从零生成前后端分离应用，十次有九次跑不起来。此外，对于不会编程的用户（零知识用户）来说，他们并不知道大模型开发时的架构选择是否合理。我的亲身体会如下：即使我跟claude说用单机部署，架构越简单越好，他依然会给我使用FastAPI+Vue的架构）。但是他自己又不一定能跑起来，靠自己debug也debug不明白。
标准化、模块化的组件是可沉淀、可积累、可复用的资产。这与那种认为“AI 产品代码是快速迭代、用后即抛”的观点不同。尤其当 AI 需要与企业现有系统（非 AI 部分）稳定对接时，健壮、可维护、可复用的代码组件是必需品。
换句话说，如果ai每次自己生成的代码不能保证100%的稳定性，那为什么不提前生成组件让他组合呢？
实际工作中发现，大部分情况下模型的整体思路实现没有问题，但是具体的细节经常会出错。当你对他屏蔽细节之后，他的性能会有效提升。