AI

1. 前言 随着2022年底以ChatGPT为代表的LLM（大语言模型）爆发式发展，AI Agent（智能体）迅速从概念走向工程实践。从早期简单的单轮对话工具，到如今能够自主规划、调用工具、持续迭代的编程Agent（如Cursor、Claude Code、Codex CLI），Agent已经成为大模型应用落地的核心形态。正如OpenAI在其官方博客中所说，Agent Loop是连接用户、模型和工具的枢纽。 作为Agent系统的核心机制，Agent Loop（智能体循环）决定了Agent如何思考、如何行动、如何与外部环境交互。这个循环的本质是：Agent接收用户输入，查询模型进行推理，模型要么产生最终回复，要么请求工具调用；Agent执行工具后将结果回灌到prompt中，再次查询模型——如此反复，直到模型停止发出工具调用、产出面向用户的assistant message为止。这个assistant message不仅是对用户的回应，更标志着Agent Loop的一个终止状态：从Agent的视角看，它的工作已经完成，控制权交还用户。 它看似简单——不过是一个"调模型、执行工具、再调模型"的循环——但要在真实产品中稳定、高效、可扩展地运行，却涉及大量精妙的工程设计和架构取舍。比如，随着对话增长，prompt长度会不断增加，而每个模型都有上下文窗口（context window）限制，因此上下文窗口管理是Agent的核心职责之一。此外，Agent执行的工具调用会修改本地环境（如读写文件），所以Agent的"输出"远不止assistant message，还包括它实际产生的代码变更等副作用。 本文是Agent实现原理系列的第一篇，将从工程实现的角度，深入剖析Agent Loop的核心原理。我们将参考Codex CLI、Claude Code、nanobot、pi等主流开源项目的实现，抽象出Agent Loop的通用模型，分析其关键设计点和工程权衡。 2. Agent Loop的本质 2.1 从"会调LLM的程序"到"Agent Runtime" 一个最朴素的Agent实现，可以写成下面这样： while true: response = call_llm(messages, tools) if response has tool_calls: results = execute_tools(response.tool_calls) messages += [response, results] else: return response.content 这段代码确实构成了Agent Loop的核心骨架，但它距离一个"能在真实产品中运行的Agent Runtime"还有很大差距。真实场景需要回答的问题包括： 工具执行出错或产生副作用时，如何优雅处理？ 用户中途插入新指令，如何不破坏当前执行上下文？ 上下文窗口超限，如何压缩而不丢失关键信息？ 多轮迭代后历史越来越长，如何保持"上下文卫生"？ 流式输出如何与工具调用无缝衔接？ 子Agent如何复用主循环的能力？ 这些问题促使Agent Loop从一个简单的while循环，演进为一组边界清晰的组件协作系统。 2.2 Agent Loop的通用抽象 无论具体实现如何差异，所有成熟的Agent Loop都共享同一套核心抽象： ...

最近由于项目事情比较多，我大量使用AI coding来帮助我开发，一周写了近两万行代码，基本上都是采用编程Agent来开发，总体感受就是：“码农的工作方式，要翻天了”。 回想起我的编程生涯，从1995年的turbo basic开始，到Visual Basic，再到C++、Java、Python等等前后端开发，总体感受还是主要靠自己手搓代码：先厘清目标，做大致的类与函数设计，再分模块敲代码，接着编译、测试、改 bug、调试、再优化，最后上线。工具能提供的帮助很有限：无非是方法与变量的提示，或是对明显的编译错误、风险点给出提醒。绝大多数时候，仍需自己一行行写代码，再交由编译器校验正确性。粗略估算，规划、编码、验证的时间占比约为 1:1:1—— 这就是传统编程的典型节奏。 2023年ChatGPT刚出现时，一开始我还是不以为然，认为只是AI来帮我生成一些代码片段，我还是需要复制粘贴到编辑器中，只是稍微节省了一点点编码的时间。主要的代码框架还是需要我自己来写，AI只是写一些函数片段而已。没想到两年后，2025年的今天，以Cursor、Claude Code为代表的AI编程工具发展如此迅猛，完全颠覆了我三十年编程习惯，让我在短短一个月内，完全接受了这由AI来主导编程和验证的新模式。 这种AI编程的流程可以简单概括为：不用做太细致的设计规划，想清楚需求后直接提给编程Agent，剩下的交给它就行。 Agent会自己设计方案、写代码、开发单元测试，完成后自动运行单测与程序验证。若失败则会根据报错修复bug，直到所有测试用例通过。整个过程中，我们只需要review代码修改、确认执行命令，其他环节全由AI全自动完成。而且AI模型编程水平之高，代码之规范，编程习惯之好，测试覆盖面之高，远超当前大部分的程序员。规划、编码和验证的时间分布，变成了2:0:1，编码因为交给AI自动完成，所以基本可以忽略不计。我们只需要多点时间想清楚需求，留点时间验证结果是否符合需求，其他精力基本不需要投入。 一开始我还是对AI编程能力持怀疑态度，尤其是对AI能否正确开发和修改大型项目，没有太多信心。然而，当我用AI来帮我完全实现了一个一万多行的基础库之后，我被AI编程彻底折服。这个库如果我手搓开发，预计需要5个完整的工作日，然而用AI来写，我只花了1天时间就高质量搞定，并通过了测试验证，工作效率提升了5倍。更有甚者，当我有一个新的想法，从设想到实现并验证通过，同时还夹杂着开会和其他事情的打断，完成只需要1个小时，而我预估如果在日常工作中手搓这个功能，还需要查文档资料，还会被其他事情打断，至少需要8个小时才能完成——从这个意义上来说，工作效率达到了8倍的提升。这就是为什么我完全接受了AI编程，因为它实实在在帮助我提升了5到8倍的开发效率提升，彻底改变了我三十年的编程方式。 在AI大模型爆发两年之后，2025年终于迎来了真正改变行业的时刻。首当其冲就是编程等脑力创作类的领域，程序员不再需要写真正的代码，而是专注于需求的理解，架构的拆解，接口规范和协议的制定，剩下的编码执行的工作，全部交给编程Agent。在这个时代，程序员更重要的素质，将是对行业需求的理解，对系统架构搭建的经验，对上下游系统的了解，对整个架构环境的认知。而具体编码的工作，则交给一群不知疲倦，打字速度奇快，拥有良好编程习惯的AI程序员来执行。而我们只需要保证，他们的产出结果符合预期即可。 这个判断进一步延续了我之前对于智能密集型组织的预测，即在新型的智能密集型组织中，脑力劳动的边际成本将趋于零，多做一个项目基本不需要增加程序员成本，只需要增加架构设计成本。传统意义上写代码的程序员，必然将被编程Agent所代替，且其成本将变成软件订阅费这类的运营支出(OPEX)。这将是对组织形态的一个巨大变化，“订阅一个cursor pro胜过招募五个初级程序员”，这种事正在从想象变成现实。 但这并不意味着程序员就要被历史所淘汰。这个职业必然迎来一次转变：即从代码开发者，升级为“设计师”或者“架构师”。未来的程序员还是需要对技术有深入的了解，加速学习产品和业务知识，能将业务问题转换为技术问题，剩下的交给一群不知疲倦的编程Agent来完成。程序员将更多担任桥梁的作用，理解需求，拆解需求，规划系统架构。这很像从手工业到工业时代的转变：工人不再靠复杂手工打造产品，而是通过机械化流水线生产，更多人力用于发掘市场机会、设计产品、验证想法。 这仅仅是一个开始！AI将会继续改造我们身边的各行各业，所有我们曾经认为“只有人类才能胜任”的脑力工作，都将被重新定义。我们既是这场变革的推动者，也是被其影响的参与者。唯有保持终身学习，才有可能在这场AI大变革中，找到自己的位置。