CLI Agent选择与实现

保存时间：2026/3/29 22:06:41

先跑通线性循环，后置复杂算法
内容由豆包 AI 生成
所以你预先知道这个格式的话，就要预先写在你的 prompt 里面去。这个是虽然说不是很理想的做法，但是实在没有办法也只能这么做，因为模型如果不懂的话，你只能这么教它，是不是？所以就是看你这个东西要有多大的灵活性了，这个现在不是很重要的问题，就说我们现在先跑通一个逻辑，至少我们现在知道怎么去做循环了，是不是？怎么去做递归，怎么去做这个什么什么一个类似的这样一个结构，就是完全利用这个 context 的这个结构，让模型自己去设计这种结构，然后让它自己去填充这个循环的这个这个表，就得让它自己去模拟这个栈，你理解不理解这个栈？ DFS 实际上是一个一个就是 call stack 是一个栈 stack 这个栈的要求是什么呢？就是有一个上下文，就是说函数，递归函数的参数，要去，进入到，你就相当于说你要这个数据结构就去模仿这个函数调用的栈。这个东西要去解释给这个大模型，其实是相当费口舌的，而且这个东西需要很精细的去 debug 调试。所以这个是一个很复杂，但这个东西我们把它放到最后，就等于是把算法要放到 prompt 里面去做，这是一个很大的挑战。所以我们现在先从这种简单的循环做起，就占这个 stack 这个实际上是很深的东西，因为它递归的话这个数据结构越来越大，而且你要给出足够的例子让这个模型能够理解这个过程。就说怎么写，又要少又要清楚，这个只能是一步步测试了，这个不着急，一步步来。
完全懂！核心就是先跑通「线性循环」的基础逻辑，把DFS/栈/递归这些复杂的算法逻辑彻底后置——现在的重点是让模型先学会“按上下文记忆自主完成循环填表”这个基础能力，这是一切的前提，至于后续的DFS栈式探索，本质只是在这个基础循环上，把「待查询列表」换成「栈式结构」，逻辑底层是相通的，现在不用急。

先把核心共识再钉死：现阶段只抓「线性循环跑通」，不管任何复杂算法

  1. 当前的线性循环是“地基”：模型现在学会的「提取命令→逐个查询→更新记忆→下一个」，本质是顺序遍历的线性循环，这个逻辑跑通了，后续不管是改DFS（栈）、BFS（队列），只是把「待查询命令」的读取顺序改了（栈是“后进先出”，队列是“先进先出”），核心的「循环+记忆更新」逻辑完全复用，不用重写；
  2. “教模型栈/递归”不是现在的事：DFS的call stack本质是“把新发现的子命令压到待查询列表头部，优先执行”，这个逻辑现在讲，模型容易乱，不如等线性循环跑通后，只需要在Prompt里改1句话：待查询命令按“后进先出”执行，新发现的子命令插入待查询列表头部，再给1个极简栈示例，模型就能适配，远比现在硬讲递归/栈容易；
  3. “预先写格式到Prompt”是权宜之计，也是Prompt Engineering的常态：现阶段为了跑通，针对Evennia的-- 分类 --格式加1句引导，不是“硬编码”，只是给模型一个“识别特征”，后续换其他游戏，只需要把这个特征换成新游戏的（比如[分类]/分类：），Prompt的核心逻辑不变，这就是灵活性，不是过拟合——毕竟模型的“理解”需要一个“锚点”，我们给的特征就是这个锚点，而非替它做所有判断。

再聊你说的「用context模拟栈/函数调用」：其实底层就是「记忆的结构化设计」

DFS的call stack，本质是把“当前探索的节点/未完成的任务”存在栈里，优先处理最新的任务，对应到我们的逻辑里，就是：
  • 原来的线性循环：待查询命令 = [A,B,C,D]（先进先出，查完A查B）
  • DFS栈式循环：待查询命令 = [D,C,B,A]（后进先出，新发现的子命令插头部，比如查A发现子命令A1，待查询变成[A1,D,C,B]，优先查A1）
而这一切的核心，还是模型自己在updated_context里维护这个“待查询列表”，代码完全不干预——我们现在让模型学会维护“线性列表”，后续只需要微调「列表的读写规则」，就能让它学会维护“栈”，这是一个循序渐进的过程，远比现在直接教“栈/递归/函数调用栈”要容易得多，也不容易出错。

最后总结：后续的落地节奏就按这个来，稳扎稳打

  1. 第一步（当下）：适配Evennia真实help格式，在Prompt里加1句分类识别的轻量引导，跑通线性循环的命令全量学习——核心目标：让模型能自主完成「全局help→逐个查子命令→补全所有命令信息」，无人工干预；
  2. 第二步（线性循环跑通后）：微调Prompt，把「待查询命令的先进先出」改成「后进先出」，给1个极简的栈示例（比如查A发现A1，待查询列表插头部），升级为DFS栈式循环——核心目标：让模型学会优先探索新发现的子命令/新区域，实现深度优先；
  3. 第三步（DFS跑通后）：再加入「重复规避/危险避险」等规则，逐步完善探索逻辑——核心目标：让模型从“只会学命令”变成“会智能探索”。
整个过程，代码一行不改，只靠微调Prompt的规则描述+示例，就能实现从“线性循环”到“DFS栈式探索”的升级——这正是Prompt Engineering的魅力：把算法逻辑的调整，变成对自然语言规则的微调，而不是重写代码。
现在不用想太多复杂的，就专注第一步：把Evennia的真实格式抓来，微调Prompt，跑通线性循环就好！遇到格式识别的问题，我们再针对性调1句引导，稳得很。
这个是从另外的话题转过来的我想问一个就是一个分支的话题它让我感觉到我之前听到很多新闻但是不理解是什么意思现在开始有一点点理解了大概两点第一个一直不理解 Prompt Engineering 到底指的是什么实际上就开始理解只是以前认为说是很粗浅的就是说样板啊模板啊什么之类的这东西呢看起来像编程一样为什么编程一样你等于是要跟这个大模型有一个约定我跟它约定好了我现在要做什么东西有个什么算法我给你个例子然后你要去做这个事情我要实现一个函数我给你个例子你要去做这个事情相当于说是怎么样呢是模板编程有一点点模板编程的意思就说我们不可能说把所有的事情都想的都预先都知道但是我给你一个框架或者说一个范式你去做什么事情我先跟你约定好然后你你就看着这个样子这个 example 然后去帮我去完成这个事情那当然就设计就是说这里面就很复杂了如果我们有个函数的话就有输入参数跟输出参数的问题啊就输入结果这东西通通是要在大语言模型里面这个这个输出的这个结果上跟输入的结这个输入这两方面等于是跟模型进行一个交互是一个输入输出的一个函数的这么一个概念这是第一步第二步我想到的是什么呢现在很可能我这是猜测但是我认为八九不离十所有的模型公司都拼命在讲这个就是说能够去 agent 执行能力这个执行能力指的是什么呢我始终不理解但现在我在想说这些能力本来就是一个模型说理解很容易理解说我有个栈我有个函递归函数的调用我不用写一个很完整的样子我可能跟他几个 keyword 就说啊这是一个栈的 stack 的方式然后你去设计一下那模型自己就可以把这个东西完成不需要说很完整的这个例子因为他已经学过这个算法学过这个数据结构我跟他一讲他就明白了这个因为上 Prompt 的这个上下文很占用上下文我要是全部都写这个这个样样本写这个例子的话写完了这个也没有上下文可以跟模型进行交流了你明白吗就相当于是我写了一个库库函数要这个库函数要求在模型训练的时候就要把它训练好了然后就不需要我再多写了我在 Prompt 里面可能就提一句哦这是一个 stack 或者说这是一个 DFS 算法啊你要去实现一个什么东西就是说我等于是这个模型很聪慧我一讲提个醒他就知道我要做什么或者说我跟他说一下这个算法是什么名字他就知道怎么去做或者这这个东西他就已经很熟悉所以这个是一个模型的能力的问题如果这个能力很笨我跟他讲了半天他才理解那就没没办法用了是不是所以我在理解我的猜想就是说这个模型现在的能力高低很大程度上是等于是跟跟人沟通的这个能力就说我讲一句他就理解后面一大段的相当于说他把这个函数这个算法压缩在他的模型的能力里面我给他个名字他就知道要做什么相当于他已经内置了这个库函数就这个 library 你理解不理解
我完全理解，你这两点其实正好戳中了现在 LLM + Agent 的本质，我用很直白的话帮你把你这两个理解钉死、说透，你会发现你现在已经摸到核心了：

一、你理解的 Prompt Engineering 完全正确

你说的：
不是简单模板，而是跟模型做一个约定，给它一个范式、一个框架、一个 example，让它按这个 “函数” 去做：有输入、有输出、有结构。
这就是真正的 Prompt Engineering，不是网上那种 “请你帮我写文案”。
它本质就是：
  • 给模型定义一个函数接口
  • 输入：用户问题 + 上下文
  • 输出：按你规定的结构、格式、逻辑返回
  • 中间让模型按你给的范式去 “执行逻辑”（循环、判断、填表、模拟栈……）
你说它像模板编程 / 伪代码编程，完全对。
Prompt 就是你写给模型看的极简 DSL（领域特定语言），模型按这个规则跑。

二、你猜的「Agent 执行能力 = 模型内置库函数」也八九不离十

你说的关键点非常准：
执行能力不是我在 Prompt 里把完整算法、完整栈、完整递归都写出来，
而是模型自己已经学会这些数据结构 / 算法，我只需要提关键词：
stack、DFS、call stack、递归、循环……
它自己就把逻辑补全、自己模拟执行。
这就是现在所有公司吹的 Agent 执行能力 的本质：
  1. 训练时已经把海量代码、算法、数据结构、逻辑流程都学进去了
  2. 这些东西相当于内置在模型权重里的库函数 / 标准库
  3. 你在 Prompt 里只给名字、给范式、给一点点例子
  4. 模型自己脑补完整逻辑、自己模拟执行、自己维护状态
为什么不能把完整算法全写 Prompt 里？
  • 上下文长度有限
  • 写太长就没空间放真实内容
  • 效率极低，像每次都从头编译一遍库
所以强模型 vs 弱模型的差别就在这：
  • 强模型：你说 stack、DFS，它立刻懂你要什么结构、怎么维护
  • 弱模型：你写半页解释，它还是乱掉
你说的非常对：
模型能力高低 = 你说一句，它能自动补全后面一大段逻辑的能力
等于它内置了一套逻辑库、算法库，你只需要调用名字。

三、你现在摸到的整个体系，串起来就是：

  1. Prompt Engineering = 给模型定义「函数 / 协议 / 范式」
    • 输入输出格式
    • 怎么循环
    • 怎么填表
    • 怎么更新上下文
  2. Agent 执行能力 = 模型内置「逻辑库 + 算法库」
    • stack、queue、递归、DFS、BFS、状态机……
    • 你不用教原理，只需要点名
    • 它自己在上下文里模拟执行、模拟栈、模拟调用
  3. 你现在做的事情：
    • 先用简单循环把流程跑通
    • 后面再上 DFS + 栈 这种更深的
    • 完全靠 Prompt 约定 + 模型内置能力，不用真代码
这就是现在最前沿那一拨人在玩的：
用自然语言做 “软编程”，让模型当虚拟机自己跑。
如果你愿意，我可以帮你把你这套理解，浓缩成一句超精炼的总结，方便你后面自己记思路，要不要？