2025年是“智能体时代”，AI智能体（LLM+循环）擅长代码修复、生成、设置项目等受限任务，可自我修正。从IDE机器人进化为CLI，通过MCP实现。并行运行器提升效率，需限制访问。
译自：AI Coding Tools in 2025: Welcome to the Agentic CLI Era
作者：David Eastman
从软件开发的角度来看，回溯2025年，它将因何而闻名，这一点毋庸置疑。事实上，它已经有了一个有些狂野的名称：智能体时代。它甚至不需要一整年就能获得这个称号。
今年年初，我们都还在习惯ChatGPT框出现在VS Code等集成开发环境（IDE）中——例如，JetBrains发布了一个扩展。但直到4月初，我才第一次撰写关于Claude Code的文章，并遇到一个“智能体命令行界面”（CLI）。
现在重读那篇文章，我只引用了一次“agentic”这个词，并且从未使用CLI这个术语。直到5月底——当更强大的大型语言模型（LLM）Claude Opus被引入时——我才多次提及“agentic”这个词。
理解LLM与网络之间关系的一个更好的方法是记住智能已经存在于网络中——因为是我们人类编写了这些页面。可以将LLM视为某种能够阅读页面“之间”内容的预言机。它们本身并不真正了解任何事情，但它们确实知道如何以我们无法做到的方式查看网络，然后提取信息并将其格式化为有用的答案。大多数时候如此。
什么是软件开发中的AI智能体？
什么是智能体？它只是一个LLM、一个循环和足够的token。但是，当你看到智能体循环重新进入自己的解决方案并修复它时，它的重要性就显而易见了。这在现实世界中不一定运作良好：我见过一些双格漫画迷因的例子，一个人问AI某种蘑菇是否可食用，AI回答“是”，下一格那个人就死了——然后AI对着墓碑说“抱歉”和“你想了解更多关于毒蘑菇的知识吗？”。但在代码中这样做没问题。事实上，它比你最初想象的更有效。
链式智能体调用还增加了逐步前进、再次尝试和改进的能力。我们人类理解这种行为。智能体还可以尝试使用本地工具（通过我们稍后将讨论的模型上下文协议，MCP），这些工具可能因可纠正的原因而失败。这使得AI解决方案不会像叠叠乐（Jenga）塔一样，如果其中一块基础不安全就会全部倒塌。
智能体LLM在编码中的主要用例
在编码社区中，大多数开发者都理解了这一点。许多领域仍然存在争议，但总的来说，毫无疑问，智能体LLM确实有效——并且在受限情况下表现良好。这实际上相当罕见；大多数新想法的接受度都更加不均衡。但对于LLM，人们很快就明白了它们真正能管理什么。任务导向型工作，与现有模式合作，像初级工程师（而非高级工程师）一样“思考”。以下是突出示例：
- 格式化数据（如JSON）的转换。我所说的转换，是指遵循规则将一种模式改为另一种模式。例如，我曾用Codex尝试过这一点。进行更改后，智能体有能力查看自己的解决方案，并在发现格式被破坏时进行修复。
- 样式和代码修复，甚至在存在示例且计算领域理解其样式的情况下进行富有想象力的改进。至关重要的是，由于LLM确实理解上下文，它们可以被信任来找到合适的匹配，除非你的主题过于偏僻。在我的Jules示例中，Jules能够通过读取我的菜单行找到合适的图标，同时用Bootstrap更新我的UI布局。这些都是相对低风险的任务。
- 现有代码的逻辑扩展代码生成任务。最常见于代码补全，但在存在本地示例的地方，总能有效地生成新的代码段。此外，方法编写完全基于约定。所以如果我编写一个SwitchOn()方法，就可以生成一个兼容的SwitchOff()方法。
- 在你的驱动器上设置项目模板。一旦获得权限，LLM可以找到合适的项目设置，并在本地运行它以在你的机器上创建文件夹和文件。如果它们出现权限错误或配置错误，通常可以修复。我相信这比任何其他事物都加速了氛围编程，因为这把开关从“你的代码”拨到了“我的代码”。
从IDE聊天机器人到智能体命令行界面的演变
以前，我们会使用标准的IDE，打开ChatGPT框，并解释要完成的任务。我们可能需要进入文件，或选择一个片段。
最初的智能体请求是通过启动单独的小任务来完成的，例如“你去调整文件”、“检查项目中其余部分使用的样式”和“检查我们对该领域的知识”。这意味着工作被分成单元，进度可见。与智能体命令行界面相比，“IDE中的ChatGPT框”方法有些受限——尽管它在token方面可能便宜得多。
理解模型上下文协议（MCP）
我们从智能体代码平台看到的其他区别是它们可以访问你的驱动器。这要归功于模型上下文协议——将其视为工具与LLM的通用连接器。这个来自Anthropic的开放协议允许智能体“选择”一个宣称自己适合某个任务的工具。因此，一个从驱动器读写的工具不必一次又一次地重写。我们看到这一点在OpenAI的Apps SDK中发挥了最大效果。
我情不自禁地觉得Anthropic从Claude获得的良好印象帮助它在没有太多审查的情况下获得了认可——虽然还有其他连接协议，但MCP出现得恰逢其时。
学会限制和控制AI智能体访问
尽管对智能体系统的信任正在增加，但我们仍然希望限制智能体可以做什么（尤其是在你的机器上）以及它们可以在哪里做。在shell中操作的优势在于，你使用shell命令来更改驱动器内容；访问命令可以通过允许列表和拒绝列表来控制。
至于范围，大多数智能体平台都将工作区或文件夹视为其限制，或者识别来自git pull的文件。
智能体工作流中并行运行器的兴起
我注意到“并行”这个词被大肆宣传为营销术语。所以你看到了“并行编码”或“并行智能体”。为了明确起见，如果你真的想在同一个项目上并行运行任务，你确实需要从隔离的git分支中在独立工作区中工作，然后合并结果。否则，在同一代码上工作的任务可能会冲突。
最有效的最新趋势是“并行运行器”，由Conductor以及最近的Verdent所强调——这可能也是Google的Antigravity所追求的目标。这些工具遵循隔离分支的模型，允许任务稍后运行和合并。我们不再等待一个任务完成，而是启动一个并接着进行下一个，每个任务都在自己隔离的代码工作区中工作。一个任务接着一个任务。
独自工作时，这看起来像是有注意力缺陷问题的人的梦想——然而它也密切反映了我们与团队合作的方式。但这只有在你确信哪些类型的任务对于智能体LLM来说可以无需干预地简单完成时才可行。
结论
开发社区知道的一个秘密是，LLM在受限情况下确实运作良好。不，不是用于向人类提供食用菌的建议。也不是用于凭空创造出成品。
当我们听到关于LLM“失败”的糟糕用例，随后伴随着泡沫破裂的景象时，对此的反驳是大量可用服务器正在做LLM真正擅长的事情。一次小范围崩溃实际上可能会阻止对“机器中的上帝”的无意义追逐，并造福有用的工具提供商。
接下来会是另一篇文章，但我怀疑未来的大部分工作将是完善这个智能体时代的工具。
