首页
学习
活动
专区
圈层
工具
发布
社区首页 >专栏 >从"写提示词"到"写循环":智能体架构的核心转变

从"写提示词"到"写循环":智能体架构的核心转变

原创
作者头像
用户12606972
发布2026-07-09 16:01:48
发布2026-07-09 16:01:48
310
举报

大模型本身只做一件事:读一段文字,吐一段文字。它不会自己读文件、跑代码、上网查资料。真正让它"能干活"的,是包裹在模型外面的那套循环系统。本文从架构设计的角度,探讨如何构建这套循环系统。

一、模型与循环:分工协作

要把一个大模型变成能解决实际问题的智能体,核心思路很清晰:

智能体 = 模型 + 循环

模型负责"想",循环负责"干",两者分工明确,缺一不可。

模型的角色

模型是智能体的"大脑",擅长理解、推理和想办法。它的核心能力是处理文本:读进去一段描述,吐出来一段方案。

但模型有天生的局限性:它只会"动嘴",不会"动手"。读不了文件、跑不了代码、上不了网。它给出的答案对不对、任务完成没完成,自己心里也没底。

循环的角色

循环是智能体的"手脚",负责把模型的意图变成真实动作。模型说要读表格,循环就真的去读;模型说要改代码,循环就真的去改,改完还能把结果还回去。

循环的运作模式很简单:想 → 做 → 看结果 → 再想,一圈圈转下去,直到把事情办成。

二、循环系统的四个核心组件

一个完整的循环系统包含四个组件:

组件

职责

核心能力

规划器

目标分解与步骤生成

理解需求、推理决策、制定计划

执行引擎

操作调度与工具调用

文件读写、代码执行、网络访问

验证器

结果校验与状态评估

正确性判定、完整性检查、质量评估

协调器

循环控制与状态管理

流程编排、异常处理、终止判定

这四个组件各司其职:规划器做决策,执行引擎落地操作,验证器检查结果,协调器控制节奏。

三、分层循环设计

复杂任务的循环不是单一的,而是多层嵌套的结构:

代码语言:txt
复制
┌─────────────────────────────────────────────────────────────┐
│                    外层循环(业务验证层)                    │
│  周期:天/周  职责:市场反馈、用户验证、业务调整             │
│  输出:需求变更、优先级调整                                  │
├─────────────────────────────────────────────────────────────┤
│                    中层循环(策略调整层)                    │
│  周期:小时  职责:方向判断、界面调整、架构优化               │
│  输出:规格变更、设计调整                                    │
├─────────────────────────────────────────────────────────────┤
│                    内层循环(代码执行层)                    │
│  周期:分钟  职责:代码生成、测试执行、Bug修复               │
│  输出:功能实现、测试报告                                    │
└─────────────────────────────────────────────────────────────┘

内层循环(分钟级)

这是最基础的一层。给定明确的规格文档和验证标准,智能体可以自主完成编码、测试和修复。人可以离开,它照样运转。

中层循环(小时级)

这一层需要人的参与。智能体写完第一版代码后,人需要判断:功能对不对?界面怎么调?架构合不合理?这些决策依赖于人的经验和对业务的理解,是AI目前无法替代的。

外层循环(天/周级)

这是最慢但最关键的一层。代码写完了,内部测试通过了,但真正的验证需要放到真实世界中——找用户试用、看数据反馈、观察市场变化。只有真实世界的验证,才能回答"这个产品到底有没有价值"。

最快的一层负责执行,最慢的一层负责决策。这个分层设计让人和AI在各自擅长的层面发挥作用。

四、关键设计原则

原则一:目标必须可验证

"所有单元测试通过、无失败"是个好目标;"把它做好看一点"不是。

循环系统的瓶颈从来不是模型,而是那个说得清"怎样才算做完"的验证器。说不清楚验证标准,循环要么原地打转,要么早早收工。

原则二:必须划清边界

无约束的循环很容易"跑过头"。让它修个小Bug,它可能跑很久,最后自作主张加一堆没人要的功能,甚至把本来能编译的代码改坏。

因此,轮次上限、修改范围、Token消耗等约束,都需要提前明确。

原则三:验证必须独立

执行和验证不能由同一个角色完成。如果让智能体自己写代码又自己验证,就像运动员自己当裁判,结果不可信。

更稳妥的做法是:一个智能体负责执行,另一个专门负责验证。最终的验收权始终保留在人手里。

五、两种模式的对比

维度

传统模式(人写提示词)

循环工程(人写循环)

谁在提示模型

人,一句一句

循环系统,自动

人的位置

盯屏幕、传信、点重试

定目标、划边界、做验收

什么时候停

人觉得差不多就停

验证器判定"达成"才停

出错了怎么办

人发现,再让它改

循环自己接住,重试

最适合

一次性的小问答

长任务、需要自主迭代的活

关键差异在于:传统模式中,是循环的驱动力;循环工程中,验证结果是循环的驱动力。这一转变让人类从"操作层"上升到"决策层",系统也具备了自我修正的能力。

六、启动条件与执行流程

要让循环系统运转起来,需要两个关键输入:

  1. 规格文档(Spec):说清楚要做成什么样的产品文档
  2. 验证标准(Evals):判断做得对不对的评测标准

有了这两样东西,循环就能自己跑起来:写代码、跑测试、发现问题、动手改、改完再测,一圈圈直到符合规格、没有明显Bug才停。

一个完整的循环流程如下:

代码语言:txt
复制
规划 → 执行 → 验证 → 判定
  ↓                    ↓
  └────────────────────┘
    未达标则反馈优化

七、工程实践建议

  1. 状态持久化:记录每轮循环的输入、输出和验证结果
  2. 可追溯性:建立完整的执行日志,支持问题回溯
  3. 渐进式授权:从低风险任务开始,逐步扩展系统权限
  4. 人工兜底:保留人工介入机制,应对边界情况

八、总结

把大语言模型转化为真正的智能体,核心在于构建一套分层循环架构。模型负责思考和规划,循环负责执行和验证,人负责设定目标和做出关键决策。

在这个架构中,跑得最快的是内层的代码执行循环,但真正稀缺的判断能力,始终存在于更慢、更外层的决策循环中。好的架构设计,就是让正确的角色在正确的层次上发挥作用。

过程变得更简单、更高效。


本文为原创内容,如需转载,请注明出处。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、模型与循环:分工协作
    • 模型的角色
    • 循环的角色
  • 二、循环系统的四个核心组件
  • 三、分层循环设计
    • 内层循环(分钟级)
    • 中层循环(小时级)
    • 外层循环(天/周级)
  • 四、关键设计原则
    • 原则一:目标必须可验证
    • 原则二:必须划清边界
    • 原则三:验证必须独立
  • 五、两种模式的对比
  • 六、启动条件与执行流程
  • 七、工程实践建议
  • 八、总结
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档