大型语言模型（LLM）代理有望成为新一代的高级编程语言，其变革性堪比 C 语言之于汇编。未来的软件开发将由多个人工智能代理协同完成，人类开发者的角色将转变为管理和指导这些代理，从而可能实现数量级上的效率提升。尽管存在对代码质量、可理解性和成本的担忧，但这些问题可以通过优秀的框架和工具来解决。一个新兴的开发范式将围绕文档、实现、对话和任务四个核心部分构建，而 MCP 等标准的出现则预示着应用孤岛的终结，不同系统间的功能与数据将能自由组合。
核心假说：新一代高级语言
大型语言模型（LLM）代理正在对所有编程语言进行革新，其影响类似于 C 语言对汇编、Java 对 C 语言的迭代。未来，人类开发者的主要工作栈将是与多个并行的、自主的代理协同工作。衡量这一假说是否成立的标准是：如果开发者使用这些代理能构建比以往多一个数量级（10倍）的功能，那么假说就是成立的。
这意味着开发者的主要工作将从编写代码转变为管理一个代理团队，以及进行更高层次的系统设计。
常见质疑与回应
对于经验丰富的开发者来说，这种转变会引发许多质疑。
“10倍的代码不等于10倍的产出” 衡量的标准是 实际交付的功能，而非代码行数。在新的模式下，“代码”实际上是给 LLM 的指令。
“LLM 只适合不会编程的人” 事实恰恰相反。许多经验丰富的程序员已经通过 LLM 大幅提升了产出。
“LLM 会让我们的编程技能退化” 很有可能。但就像我们现在不再纠结于汇编或 C 语言技能的退化一样，只要新工具能带来更高的生产力，我们就会适应它。
“LLM 生成的代码质量很差” 几乎可以肯定。但只要它足够高效且能正常工作，系统就能运转。系统本身可能不那么“优雅”，但它能用。
“使用 LLM 代理成本高昂” 如果它们能为你带来50%的生产力提升，相对于你的薪资，其成本并不高。而且 LLM 的价格只会越来越便宜。
真正的核心挑战
抛开上述情绪化的反对意见，有两个问题直指要害：
- 质量： 我们是否在用 LLM 生成的代码构建一个未来会崩溃的“垃圾场”？
- 可理解性： LLM 是否会生成如此大量的代码，以至于我们永远无法理解或控制它？
任何一个可行的 LLM 编程框架都必须以 质量 和 可理解性 作为其核心目标。
未来开发模式的样貌
一个基于 LLM 代理的近未来开发系统，可能包含以下几个共同元素：
- 文档 (Documentation): 一系列描述系统规格的 Markdown 页面，包括目的、核心实体、接口、约束和编码标准。
- 实现 (Implementation): 实际运行的代码库和所有数据。代码库应能根据文档重新构建。
- 对话 (Dialogs): 多个代理在执行任务时产生的思考过程和代码文本流。人类可以随时查看或介入这些对话。
- 任务 (Tasks): 一系列动态的、离散的工作单元，同样以 Markdown 页面的形式表达，并有明确的状态（如待办、进行中、完成）。
在这个模型中，文档和实现是 存量，而对话和任务是 流量。人类开发者的大部分时间将用于与代理互动，而不是直接修改代码。
代理的角色与协作
由于底层模型是通用的，代理可以扮演多种角色，开发者可以试验不同的协作模式：
- 独立工作者： 从头到尾独立完成任务。
- 管理代理： 负责协调和安排下一步工作。
- 质量保证 (QA) 代理： 尝试破坏新功能以测试其健壮性。
- 审查代理： 在没有上下文的情况下审查新功能。
- 合并代理： 解决代码冲突。
打破孤岛：MCP 标准的机遇
MCP（一种供 LLM 调用工具的标准）的出现，为打破当前应用孤岛、构建一个更自由的互联网提供了机会。
MCP 可以被视为一种通用的 XMLHTTPRequest。它让 AI 代理能够从任何孤立的应用中提取功能和数据，并将其放置在你选择的动态画布上。
这意味着，你可以简单地告诉代理“从 Salesforce 中获取 X 数据”，它就会为你获取数据，并按照你的要求（例如在文档页面中）进行可视化。这真正预示着应用孤岛的终结。
最终，新的开发系统将以文档和代理为前端，以底层技术栈为后端。通过一个良好的底层基础，LLM 输出的代码量会更少、更易于理解，从而大幅提升我们构建的系统的质量与性能。