别再手写Prompt了：让AI代理自己提示自己

从手动提示到自动循环：AI编程范式的转变

这是一个每月都值得重复的提醒：你不应该再手动给编程代理写提示词了，你应该设计让代理自己提示自己的循环系统。

这个观点来自YouTube上一位开发者对AI编程工作流的深度反思。他坦言，尽管早就接触过各种代理循环的概念，但真正接受这一理念却经历了一个漫长的过程。而事实证明，走在前面的人（他提到的Pete）又一次说对了。

传统代理循环的困境：酷炫但不实用

像Ralph Loop这样的早期代理循环确实帮助开发者理解了AI代理如何随着时间推移完成更多任务。代理循环的核心思想源自诺伯特·维纳（Norbert Wiener）在1948年提出的控制论中的反馈回路（Feedback Loop）——系统将输出结果重新作为输入的一部分，从而实现自我调节。在AI编程领域，早期的代理循环尝试让大语言模型在生成代码后自动执行、检测错误、再修复，形成"计划-执行-观察-修正"的闭环。这一模式在学术上被具体化为ReAct（Reasoning + Acting）框架，由Yao等人在2022年提出，让LLM在推理和行动之间交替进行，每一步的观察结果都会影响下一步的推理方向。与传统软件工程中的REPL（Read-Eval-Print Loop）有异曲同工之妙，但引入了LLM的推理能力，使循环具备了更强的自适应性。

然而，这些循环也带来了一个严重的副作用——错误率大幅上升。

代理在循环中做出的修改虽然看起来很酷，但实际生产力并不高。问题的根源在于，早期循环缺乏有效的质量控制机制和状态管理能力，代理可能在修复一个bug的同时引入两个新bug，形成"修复-破坏"的恶性循环。像AutoGPT、BabyAGI等早期项目虽然引发了巨大关注，但它们的实际任务完成率往往不到30%，核心问题在于这些系统在遇到歧义或错误时容易陷入"幻觉循环"——代理基于错误的前提不断生成看似合理但实际错误的输出。最终，很多人发现自己总是回到老路子上：手动编写精心设计的提示词，一步步指导代理完成任务。这是AI编程实践者的共同经历——新工具新方法试了一圈，最后还是回到"手搓Prompt"的舒适区。

转折点：让代理自己提示自己

真正的突破发生在开始系统性地构建**自提示循环（Self-Prompting Loop）**之后。以下是几个关键实践：

代理自审代码：构建生成-审查闭环

不再依赖人工审查代理生成的代码，而是设置一个自动化系统，让代理自己审查代码、给出反馈、调整修改，然后触发重新审查。这形成了一个完整的闭环：

生成 → 审查 → 反馈 → 修正 → 再审查

这种机制让代码质量在每一轮迭代中持续提升，而无需人工介入每一个细节。值得注意的是，这里的"审查"并非简单的语法检查，而是包含逻辑一致性验证、代码风格规范检查、潜在安全漏洞扫描等多维度评估。代理在审查角色中被赋予了与生成角色不同的系统提示和评估标准，这种"角色分离"策略有效避免了自我确认偏差——就像软件工程中代码作者不应该是唯一的代码审查者一样。

在技术实现层面，角色分离通常通过不同的系统提示（System Prompt）和温度参数（Temperature）来实现。生成代理通常使用较高的温度（如0.7-0.8）以鼓励创造性解决方案，而审查代理则使用较低的温度（如0.1-0.2）以确保评估的严谨性和一致性。更高级的实现还会使用不同的模型——例如用Claude进行代码生成，用GPT-4o进行代码审查，利用不同模型的认知偏差差异来提高缺陷检出率。这种多模型交叉验证的方法在学术上被称为"LLM-as-Judge"范式，已有研究表明其在代码质量评估上的准确率可以接近人类专家水平。

用Hermes代理主动获取上下文

这是一个思维方式的根本转变。过去，开发者需要自己去寻找相关上下文信息，然后喂给代理。现在，通过Hermes代理来主动将上下文带到面前，而不是自己出去寻找。

Hermes代理的命名取自希腊神话中的信使之神，其核心功能是充当信息中介——在代理执行任务前，主动检索、筛选和整合所需的上下文信息。这解决了大语言模型的一个根本性限制：上下文窗口（Context Window）的有限性。即便最新的模型已经支持数十万token的上下文长度，开发者仍然面临"该把什么信息放进去"的选择难题。Hermes代理的做法类似于RAG（检索增强生成，Retrieval-Augmented Generation）架构的进化版——它不仅检索文档，还能理解当前代码库的结构、依赖关系、历史变更记录，甚至项目的架构决策文档，然后将最相关的信息自动注入到后续代理的工作上下文中。

RAG最初由Meta AI在2020年提出，核心思想是在生成前先从外部知识库检索相关信息，传统实现使用向量数据库（如Pinecone、Weaviate、ChromaDB）将文档切片后进行语义检索。Hermes代理代表的进化方向被业界称为"Agentic RAG"——检索过程本身由AI代理驱动，能够进行多跳推理（Multi-hop Reasoning），即根据第一次检索的结果决定是否需要进一步检索、检索什么内容。在代码库场景中，这意味着代理不仅能检索相关文件，还能追踪函数调用链、理解模块间的依赖关系图谱，甚至分析Git历史来理解某段代码为什么被写成当前的样子。这种深度上下文理解能力是传统关键词搜索或简单向量检索无法实现的。

这意味着代理不仅仅是执行者，更是信息的收集者和组织者。它们能够理解当前任务需要什么样的背景知识，并自主去获取和整合这些信息。

接受一个颠覆性的结论

最终得出了一个颠覆认知的结论：你的大多数代理运行，可能不应该使用你手写的提示词。

换句话说，人类的角色应该从"逐条下达指令"转变为"设计运行机制"。

为什么自提示循环如此重要

这个观点的核心逻辑其实很清晰：

• 人类提示词存在天然瓶颈：我们在编写Prompt时，受限于自己对问题的理解深度和上下文的掌握程度。而代理在执行过程中，往往能发现我们预料不到的问题和细节。这就像软件项目管理中的一个经典认知：项目开始时，团队对需求的理解总是最浅的，随着开发推进才会逐渐深入——这在敏捷开发方法论中被称为"需求的渐进明细"（Progressive Elaboration）。自提示循环让代理能够在执行过程中不断深化对任务的理解，而非被锁定在人类最初那个可能不完整的认知框架中。

• 循环产生涌现能力：当代理能够审查自己的输出、发现问题、自主修正时，整个系统的能力上限远超单次人工提示所能达到的水平。涌现能力（Emergent Capabilities）是复杂系统理论中的核心概念，指系统整体表现出单个组件不具备的能力。在自提示循环中，涌现体现为：代理在审查自己代码时可能发现潜在的边界条件问题，而这些问题在最初的人类提示中根本没有被提及。这与软件工程中的"橡皮鸭调试法"有相似之处——解释代码的过程本身就能暴露问题。不同的是，AI代理不仅能发现问题，还能立即生成修复方案并验证其正确性，整个过程在秒级完成。

• 规模化的关键所在：手动编写每一个提示词是不可扩展的。设计好循环机制后，代理可以在最小人工干预下持续高质量地工作，这才是真正可规模化的AI编程方式。从经济学角度看，手动提示的边际成本几乎恒定——每个新任务都需要人类投入相近的时间和精力；而自提示循环的边际成本则随着系统成熟而递减，因为循环机制一旦设计完善，就可以复用于大量相似任务。这与DevOps领域的核心理念不谋而合：前期投入自动化基础设施的成本虽高，但长期来看，自动化带来的效率提升和一致性保障远超手动操作。

实践启示：从Prompt工程师到代理系统设计师

这一趋势对AI编程实践者的启示是深远的。开发者的角色正在从"提示词工程师"转变为"代理系统设计师"。

Prompt工程（Prompt Engineering）自2022年ChatGPT发布以来迅速成为一门显学，从零样本提示（Zero-shot）、少样本提示（Few-shot）到思维链（Chain-of-Thought）、思维树（Tree-of-Thought），技术不断演进。然而，这些方法本质上仍是"单轮优化"——试图在一次交互中最大化输出质量。代理系统设计则是一种根本不同的思路，它借鉴了分布式系统和微服务架构的理念：将复杂任务分解为多个代理协作完成，每个代理有明确的职责边界，通过消息传递和状态管理实现协调。

当前业界已经涌现出多个代理编排框架，它们代表了不同的设计哲学。LangGraph（由LangChain团队开发）基于有向无环图（DAG）的概念，将代理工作流建模为状态机，每个节点是一个代理操作，边代表状态转换条件，特别适合需要精确控制流程的场景。CrewAI采用"角色扮演"范式，开发者定义不同角色的代理（如架构师、开发者、测试员），框架负责协调它们的协作。微软的AutoGen则强调多代理对话，代理之间通过自然语言消息进行协商和任务分配。2024年以来，Anthropic的MCP（Model Context Protocol）协议的出现进一步标准化了代理与外部工具的交互方式，使得代理循环系统可以更方便地接入IDE、版本控制、CI/CD管道等开发基础设施。这些框架提供的正是构建自提示循环系统的基础设施。

核心工作不再是写出完美的Prompt，而是：

1. 设计有效的反馈循环——让代理能够自我检查和修正，形成持续改进的闭环。这需要明确定义每一轮迭代的评估标准：什么算"通过"，什么需要"重做"，以及如何量化代码质量的提升。

2. 构建上下文获取机制——让代理主动理解任务背景，而非被动等待人类投喂信息。这涉及到代码库索引、文档解析、API规范提取等一系列工程化工作，本质上是在为代理构建一个结构化的"项目记忆"。

3. 建立质量门控——在循环中设置合理的检查点和退出条件，防止无限循环。这包括设定最大迭代次数、定义收敛条件（如连续两轮审查无新问题）、以及在检测到代理"原地打转"时自动升级为人工介入。在实践中，定义合理的收敛条件是一个关键的工程挑战。简单的"连续N轮无新问题"策略可能导致代理在表面上达成一致但实际上遗漏了深层问题。更稳健的方法包括：引入多维度评分矩阵（功能正确性、代码可读性、性能、安全性各占权重），设定每个维度的最低阈值；使用"对抗性审查"——在常规审查通过后，额外运行一轮专门寻找边界条件和极端情况的审查；以及建立"置信度衰减"机制——如果代理在第5轮仍在做实质性修改，系统会自动降低对最终输出的置信度评分并标记为需要人工复核。

4. 管理错误传播——通过分层校验机制，避免早期循环中错误率飙升的问题。具体策略包括：在每轮修改后运行自动化测试套件、使用差异对比（diff）确保修改范围可控、以及引入独立的"仲裁代理"在生成代理和审查代理产生分歧时做出最终判断。

这套方法已经在实际项目中交付了大量代码，积累了丰富的实战经验。这不是理论推演，而是经过验证的生产力提升路径。

总结

从手动提示到自动循环，AI编程正在经历一次静悄悄的范式转变。那些还在花大量时间精雕细琢单个Prompt的开发者，可能需要重新审视自己的工作方式了。

这场转变的本质，与软件工程历史上的多次范式跃迁一脉相承：从汇编语言到高级语言，从手动内存管理到垃圾回收，从命令式编程到声明式编程——每一次进步的核心都是将低层级的重复劳动抽象化，让人类专注于更高层级的系统设计。自提示循环正是这一趋势在AI编程时代的最新体现：我们不再需要手动编排每一步操作，而是设计好规则和机制，让系统自行运转。

未来属于那些能够设计出高效代理循环系统的人——让AI不仅执行你的指令，更能自己思考下一步该做什么。与其做一个更好的Prompt写手，不如成为一个更好的系统设计师。

核心要点

核心要点