AI Agent开发新思路：用控制流取代堆提示词，构建更可靠的Agent系统

一篇在Hacker News上引发热议的技术文章（471pts）提出了一个值得关注的观点：当前AI Agent开发过度依赖提示词工程，但真正让Agent可靠工作的不是更多提示词，而是控制流设计。这个观点对正在构建AI Agent的开发者来说很有参考价值。

当前Agent开发的问题

目前构建AI Agent的主流方式是不断优化提示词：写更详细的系统提示、添加更多示例、设计更复杂的提示模板。但这种方式存在根本性的局限：

• 提示词不可靠：即使最精心设计的提示，模型也可能忽略或误解
• 复杂度爆炸：任务越复杂，提示词越长，模型越容易出错
• 调试困难：Agent行为异常时，很难定位是哪个提示出了问题
• 不可预测：同样的提示在不同上下文中可能产生不同结果

控制流的核心思路

作者建议用传统的控制流结构（条件判断、循环、状态机、错误处理）来约束Agent行为，而不是依赖提示词来”教”Agent该怎么做。

确定性优先

能用确定性代码处理的逻辑，不要交给LLM。数据解析、API调用、格式转换等都应该是硬编码的。

LLM只做判断

把LLM的职责限制在”做判断”上，而不是”做决策+执行”。让LLM判断下一步该做什么，但由控制流来执行。

状态机模式

用有限状态机定义Agent的可能状态和转换条件，LLM只负责选择转换方向。

错误恢复用代码处理

用传统的try-catch和重试机制处理错误，而不是让LLM自己决定如何恢复。

实践指南：什么时候用什么

适合用提示词的场景

• 理解自然语言输入
• 生成自然语言输出
• 做语义判断（如：这个请求是否合理？）
• 从非结构化文本中提取结构化信息

适合用控制流的场景

• API调用和数据处理
• 权限检查和安全验证
• 多步骤任务的流程控制
• 错误处理和重试逻辑
• 并发和超时管理

架构对比示例

以客服场景为例，对比两种方式：

提示词方式（不可靠）：把所有业务逻辑塞进系统提示，让LLM自己判断该查订单还是该退款还是该转人工。问题是LLM可能在复杂场景下做出错误判断，而且每次调用都消耗大量token。

控制流方式（可靠）：让LLM只负责理解用户意图（分类为”退款””查询””投诉”等），然后由代码根据分类结果执行对应逻辑。退款就调退款API，查询就查数据库，超过阈值就转人工。每一步都是确定性的，可测试的。

对Agent开发者的启示

1. 不要把Agent当全能选手：明确LLM擅长什么（语言理解），不擅长什么（复杂逻辑）
2. 控制流是可靠性保障：确定性代码的行为可预测，LLM行为不可预测
3. 模块化设计：把Agent拆分成小的、可测试的模块，而不是一个巨大的提示
4. 可观测性：控制流天然支持日志和监控，纯提示词方案则难以追踪

这篇文章的核心观点对当前”提示词万能”的风气是一个有价值的纠偏。构建可靠的AI Agent，关键不是写更好的提示词，而是设计更好的系统架构，让LLM在确定性的框架内发挥其语言理解的优势。

本文参考来源：Agents need control flow, not more prompts（Hacker News讨论 471pts）