1. 从标题拆解这个项目到底在做什么“赋饭-九天猜猜大模型Agent智能体开发实战”这个标题第一次看到的时候我愣了一下——“赋饭”是什么“九天猜猜”又是什么但仔细拆开看其实它指向的东西非常明确这是一个围绕大模型Agent智能体开发的实战项目核心玩法是让智能体在九天的时间周期内完成一系列“猜猜”类的交互任务。说白了就是用大模型搭一个能自主决策、能调用工具、能多轮交互的智能体然后把它扔到一个有明确规则和反馈机制的环境里去跑。我之所以对这个方向感兴趣是因为过去一年多我陆陆续续做过好几个Agent相关的项目从最简单的单轮问答机器人到带工具调用的任务型助手再到多智能体协作的小型系统踩过的坑可以说是一箩筐。而“九天猜猜”这种带时间约束和游戏化反馈的形式恰好是把Agent开发中最核心的几个难点——意图理解、状态管理、工具编排、失败恢复——全部压缩到一个高密度的实战场景里。你没法靠堆prompt糊弄过去因为环境会给你真实的反馈猜错了就是猜错了工具调错了就是调错了。这篇文章我想做的事情很直接把这个项目从架构设计到落地实现的完整思路拆开讲清楚。不管你是刚接触Agent开发的新手还是已经做过一些demo但总觉得“跑起来容易、跑稳很难”的同行我都希望能从里面拿到可以直接复用的东西。我会重点讲清楚三件事第一为什么这类Agent的架构要这么设计每个模块背后的取舍逻辑是什么第二具体到代码层面核心环节怎么实现参数怎么选坑在哪里第三当Agent表现不如预期时怎么系统性地排查和调优而不是靠玄学改prompt。适合读这篇内容的人我大致画个像你最好对Python有一定基础听说过大模型的function calling或者tool use机制知道什么是system prompt、什么是多轮对话上下文。如果你还自己动手写过哪怕一个最简单的Agent demo那读起来会更顺畅。但即使你完全没碰过Agent只要你能看懂基本的代码逻辑我也会尽量把每个概念用生活化的方式解释清楚让你不至于卡在术语上。2. 整体架构设计与核心思路拆解2.1 为什么选“九天猜猜”这种任务形态来做Agent实战先说说我为什么觉得“猜猜”类任务特别适合拿来练Agent开发。很多人入门Agent的时候喜欢做“查天气”“订机票”这种任务看起来实用但实际上这类任务的反馈链条很长你很难判断Agent到底是哪一步出了问题。而猜猜类任务不一样它的反馈是即时的、明确的、可量化的——猜对了就是对了猜错了就是错了而且通常还会告诉你“高了”还是“低了”、“近了”还是“远了”。这种密集的反馈信号对于调试Agent来说简直是福音。“九天”这个时间约束也很有意思。它逼着你在有限的时间内做出决策不能无限期地试探下去。这对应到Agent开发里就是预算控制和探索与利用的平衡。你手里的工具调用次数是有限的每一轮交互都有成本怎么在信息不完整的情况下做出最优决策这本身就是Agent智能的核心体现。我在实际做这个项目的过程中发现很多Agent之所以表现差不是因为模型不够聪明而是因为没有一个好的决策策略——该探索的时候在利用该收敛的时候还在乱试。另外“赋饭”这个词我理解下来应该是“赋予饭碗”或者“赋能”的一种俏皮说法核心意思是让Agent具备自主完成任务的能力而不是每一步都靠人喂。这其实点出了Agent和普通Chatbot的本质区别Chatbot是被动的你问一句它答一句Agent是主动的它有一个目标会自己规划路径、调用工具、根据反馈调整策略直到目标达成或者预算耗尽。2.2 Agent核心模块的划分与职责边界我在设计这个Agent的时候把它拆成了五个核心模块每个模块的职责边界划得很清楚这样后面排查问题的时候才能快速定位。第一个模块是感知与解析层。这一层负责接收环境返回的原始信息把它转化成Agent能理解的结构化数据。比如环境说“你猜的数字高了”这一层要把它解析成{direction: high, confidence: 1.0}这样的结构。听起来很简单但实际做的时候你会发现环境的反馈格式可能是不固定的有时候是自然语言有时候是结构化数据有时候还夹杂着噪声。所以这一层需要有一定的鲁棒性不能假设输入永远是干净的。第二个模块是状态管理。这是很多新手容易忽略的地方。Agent在多轮交互中会产生大量的中间状态已经猜过哪些值、每次猜测的结果是什么、当前的信息熵是多少、还剩多少轮预算。这些状态如果不管理好Agent就会重复犯错或者做出前后矛盾的决策。我的做法是用一个显式的状态对象来承载所有信息每一轮结束后更新这个对象下一轮决策时只从这个对象里读数据不依赖模型自己去“记住”上下文。第三个模块是决策与规划。这是Agent的大脑负责根据当前状态决定下一步做什么。决策可以很简单比如“二分查找”也可以很复杂比如“根据历史反馈估计目标值的概率分布然后选择信息增益最大的猜测”。我实际做下来发现对于猜猜类任务基于信息熵的决策策略比单纯的二分法要稳得多尤其是在反馈有噪声的情况下。第四个模块是工具调用与执行。Agent需要调用外部工具来执行动作比如提交一个猜测值、查询历史记录、计算统计量等。这一层的关键是错误处理和重试机制。工具调用失败是常态网络超时、参数格式错误、返回结果不符合预期这些都会发生。如果没有好的重试和降级策略Agent很容易卡死在某一步。第五个模块是反思与调优。这个模块不是必须的但我强烈建议加上。它负责在每一轮或者每几轮之后回顾一下之前的决策质量看看有没有更好的策略或者有没有系统性的偏差需要纠正。比如如果发现Agent连续三轮都在同一个区间里打转那可能就是决策策略出了问题需要触发一次反思。2.3 技术选型为什么用这套方案而不是别的在技术选型上我做了几个关键决策这里把背后的考量说清楚。大模型的选择我用的是一个中等规模的模型没有追求最大参数量的版本。原因很简单Agent开发的核心瓶颈往往不在模型的“智商”而在指令遵循的稳定性和工具调用的准确性。一个中等模型如果prompt设计得好在猜猜类任务上的表现可以非常接近大模型但推理成本和延迟要低得多。而且九天的时间周期意味着你要反复跑很多次实验成本是一个必须考虑的因素。Agent框架的选择我没有用那些重型的Agent框架而是自己写了一个轻量的调度循环。原因是我发现很多框架为了通用性做了太多抽象导致调试的时候很难看清楚到底发生了什么。自己写的话每一行代码都在掌控之中出问题的时候可以直接打断点看状态。当然如果你的项目复杂度很高用框架也不是不行但对于猜猜类任务自己写反而更快。工具调用的实现方式我用的是原生的function calling机制没有用ReAct那种文本解析的方式。Function calling的好处是结构化、可靠、不容易解析错。ReAct的好处是灵活、不依赖特定模型的function calling能力。我实测下来在猜猜类任务上function calling的稳定性明显更好因为工具的参数结构很固定不需要模型去“发挥”。状态存储我用的是内存中的字典对象没有上数据库。因为九天猜猜的任务周期很短状态量也不大用数据库反而是过度设计。但如果你要做多Agent协作或者需要持久化状态那就要考虑用Redis或者SQLite了。3. 核心细节解析与实操要点3.1 猜猜类Agent的决策策略从二分法到信息熵很多人做猜猜类Agent的第一反应就是用二分查找。这没错二分查找在理想情况下是最优的每次都能把搜索空间减半。但实际做下来你会发现二分查找有几个致命的假设第一反馈必须是准确的第二搜索空间必须是均匀的第三目标值必须是静态的。这三个假设在真实场景里往往都不成立。我举个例子。假设目标值是在1到100之间但反馈机制是这样的如果你猜的数离目标值在10以内它会说“很近了”如果在10到30之间它会说“有点远”如果超过30它会说“太远了”。这种反馈的粒度很粗二分查找就不好用了因为“很近了”并不告诉你到底是高了还是低了。这时候更好的策略是基于信息熵的决策。具体做法是维护一个关于目标值的概率分布每次猜测后根据反馈更新这个分布然后选择下一个猜测值使得期望信息增益最大。信息增益的计算方式是猜测某个值后所有可能的反馈结果带来的熵减的期望值。用生活化的类比来解释你在一间黑屋子里找一把钥匙二分查找相当于每次都走到屋子正中间摸一下然后根据“有”或“没有”来决定往左还是往右。但如果你的手只能感觉到“很近”“有点远”“很远”这三种模糊的反馈那二分查找就不灵了。信息熵策略相当于你先根据房间的布局估计钥匙最可能在哪里然后去那个最可能的地方摸摸完之后根据手感更新你的估计再去下一个最可能的地方。实操中我会把搜索空间离散化成若干个桶每个桶有一个概率值。初始时概率均匀分布。每次猜测后根据反馈类型计算每个桶的后验概率。然后计算每个候选猜测值的信息增益选最大的那个。这个计算量不大对于100个桶的搜索空间一次决策的计算时间在毫秒级别。注意信息熵策略在反馈噪声很大的时候优势最明显。如果反馈是精确的“高了/低了”二分法其实就够了没必要上信息熵因为计算开销虽然不大但代码复杂度会上升。3.2 状态管理的设计模式与常见陷阱状态管理这块我想多聊几句因为我见过太多Agent项目在这里翻车。最常见的错误是把所有状态都塞进对话历史里让模型自己去“记住”。这种做法在小规模、短周期的任务里勉强能用但一旦轮次多了模型就会开始遗忘、混淆、甚至编造历史。我的做法是显式状态 最小上下文。显式状态就是一个Python字典或者dataclass里面存所有需要跨轮次传递的信息。最小上下文是指每次调用模型时只把当前决策必需的信息放进prompt里而不是把整个对话历史都塞进去。具体来说我的状态对象大概长这样from dataclasses import dataclass, field from typing import List, Dict, Optional dataclass class GuessState: round: int 0 max_rounds: int 20 history: List[Dict] field(default_factorylist) probability_distribution: Optional[Dict[int, float]] None last_feedback: Optional[str] None budget_remaining: int 20 consecutive_failures: int 0每一轮结束后更新这个对象。下一轮决策时从对象里读取需要的信息组装成prompt。这样做的好处是状态是可控的、可检查的、可序列化的。出问题的时候你可以直接把状态打印出来看一目了然。还有一个容易踩的坑是状态更新的原子性。如果一轮交互涉及多个步骤比如先调用工具A再根据A的结果调用工具B那状态更新必须等所有步骤都成功后再一次性提交。否则如果中间某一步失败了状态就会处于一个不一致的中间态下一轮决策就会基于错误的信息。我的做法是用一个“事务”的概念来包裹一轮交互先在一个临时副本上做所有操作全部成功后再把副本替换掉原状态。如果中途失败原状态不变Agent可以安全地重试。3.3 工具调用的参数设计与错误处理工具调用是Agent和外部世界交互的接口设计得好不好直接决定了Agent的稳定性。我在这个项目里定义了三个核心工具第一个是submit_guess接受一个整数参数value返回环境的反馈。这个工具的关键是参数校验。模型有时候会传进来一个字符串、一个浮点数、或者一个超出范围的值。如果不校验环境可能会报错或者更糟糕静默地返回一个无意义的结果。我的做法是在工具函数入口处做严格的类型检查和范围检查不合法就直接返回一个明确的错误信息让模型知道参数有问题。第二个是get_history返回之前所有猜测和反馈的记录。这个工具看起来简单但要注意返回数据的格式。如果返回的是原始的历史列表可能会很长消耗大量token。我的做法是返回一个摘要版本只包含最近N轮的记录以及一些统计量比如当前搜索区间的上下界、平均猜测值等。第三个是calculate_entropy根据当前的概率分布计算信息熵。这个工具是给决策模块用的不是给模型直接调用的。我把它单独拿出来是为了让决策逻辑和模型推理解耦。模型负责理解反馈和生成候选猜测熵计算这种确定性的事情交给代码来做更可靠。错误处理方面我总结了一个三层防御的策略第一层是参数校验在工具函数入口处拦截明显不合法的输入。第二层是异常捕获用try-except包裹工具调用的核心逻辑捕获网络超时、API限流等运行时异常。第三层是降级策略如果某个工具连续失败超过阈值就切换到备用方案。比如submit_guess连续失败三次就暂停调用先检查环境状态或者切换到本地模拟环境继续跑。实操心得工具调用的错误信息一定要详细不要只返回“调用失败”。要包含失败原因、失败参数、重试建议。这些信息会进入下一轮的prompt帮助模型做出更好的决策。我见过很多项目在这里偷懒结果模型完全不知道发生了什么只能瞎猜。3.4 Prompt工程让模型稳定输出结构化决策Prompt工程在Agent开发里的地位很微妙。一方面它确实很重要好的prompt能让模型的表现提升一个档次另一方面它又不是万能的如果架构设计有问题再好的prompt也救不回来。我在这个项目里的prompt设计遵循几个原则第一角色定义要具体。不要只说“你是一个智能助手”而要说“你是一个猜数字游戏的玩家你的目标是在最少的轮次内猜中目标值。你每次可以提交一个1到100之间的整数环境会告诉你猜测是高了、低了还是很接近”。第二输出格式要严格约束。我会在prompt里明确要求模型输出JSON格式并且给出schema。比如{ thought: 你的推理过程, action: submit_guess, parameters: { value: 42 } }第三few-shot示例要精选。我会放2到3个完整的交互示例展示从观察到决策的完整过程。示例不要多多了会占用大量token而且模型可能会过度模仿示例中的具体数值而不是学习决策逻辑。第四温度参数要调低。猜猜类任务需要的是稳定和理性不是创意。我把temperature设在0.2左右top_p设在0.9。实测下来这个配置在保证一定探索性的同时避免了模型输出过于随机。还有一个细节是反馈的呈现方式。环境返回的原始反馈可能是“高了”或者“低了”但我会在prompt里把它转化成更丰富的信息比如“你猜的42高了目标值在1到41之间”。这样做的好处是模型不需要自己去推理区间更新直接拿到更新后的区间就行减少了出错的机会。4. 实操过程与核心环节实现4.1 环境搭建与依赖安装先说一下我的开发环境。操作系统是常见的Linux发行版Python版本是3.10这个版本对类型提示和异步支持都比较好。大模型的调用我走的是标准的API接口没有用什么特殊的SDK就是普通的HTTP请求这样依赖最少出问题也容易排查。依赖安装很简单核心就是几个包pip install requests numpy python-dotenvrequests用来发HTTP请求numpy用来做概率计算和熵计算python-dotenv用来管理API密钥等环境变量。我没有用任何Agent框架所以不需要装那些重型依赖。项目目录结构大概是这样guess-agent/ ├── .env ├── main.py ├── agent/ │ ├── __init__.py │ ├── state.py │ ├── decision.py │ ├── tools.py │ └── llm_client.py ├── env/ │ ├── __init__.py │ └── guess_env.py └── utils/ ├── __init__.py └── entropy.py这个结构的好处是职责清晰。agent/目录放Agent相关的逻辑env/目录放环境模拟utils/放通用工具函数。后面要替换环境或者替换模型只需要改对应的目录不会牵一发而动全身。4.2 环境模拟器的实现因为“九天猜猜”的原始环境我拿不到所以我写了一个模拟环境来复现核心的交互逻辑。这个模拟环境支持三种反馈模式精确反馈高了/低了、模糊反馈很接近/有点远/很远、噪声反馈有一定概率返回错误的方向。import random class GuessEnvironment: def __init__(self, target: int, mode: str precise, noise: float 0.0): self.target target self.mode mode self.noise noise self.round 0 def submit(self, value: int) - dict: self.round 1 if self.mode precise: if value self.target: return {result: correct, round: self.round} elif value self.target: return {result: high, round: self.round} else: return {result: low, round: self.round} elif self.mode fuzzy: diff abs(value - self.target) if diff 0: return {result: correct, round: self.round} elif diff 5: return {result: very_close, round: self.round} elif diff 15: return {result: close, round: self.round} else: return {result: far, round: self.round}噪声反馈的实现是在精确反馈的基础上以一定概率翻转结果。比如noise0.1意味着有10%的概率把“高了”说成“低了”。这个模拟器虽然简单但足够用来测试Agent的鲁棒性了。4.3 决策模块的核心代码决策模块是整个Agent最核心的部分。我把它分成两步第一步是候选生成第二步是候选评估。候选生成用模型来做让模型根据当前状态生成若干个可能的猜测值。候选评估用代码来做计算每个候选的信息增益选最大的那个。import numpy as np from typing import List, Dict def compute_entropy(probs: np.ndarray) - float: probs probs[probs 0] return -np.sum(probs * np.log2(probs)) def expected_info_gain(guess: int, probs: np.ndarray, feedback_model: Dict) - float: current_entropy compute_entropy(probs) expected_entropy 0.0 for outcome, likelihood in feedback_model.items(): posterior update_posterior(probs, guess, outcome) expected_entropy likelihood * compute_entropy(posterior) return current_entropy - expected_entropyupdate_posterior函数根据反馈结果更新概率分布。对于精确反馈如果结果是“高了”那就把所有大于猜测值的桶的概率置零然后重新归一化。对于模糊反馈就根据反馈的粒度来调整概率。这里有一个细节概率平滑。如果直接把某些桶的概率置零那万一反馈是错的噪声模式Agent就永远找不到正确答案了。所以我会给每个桶保留一个很小的基础概率比如0.001这样即使反馈有噪声Agent也有机会纠正。4.4 主循环的调度逻辑主循环负责把各个模块串起来控制整个交互流程。它的逻辑大概是初始化状态和环境进入循环直到猜中或者预算耗尽每一轮组装prompt - 调用模型 - 解析输出 - 执行工具 - 更新状态如果连续失败次数超过阈值触发反思或降级循环结束后输出结果和统计信息def run_agent(env, max_rounds20): state GuessState(max_roundsmax_rounds) while state.round max_rounds: prompt build_prompt(state) response call_llm(prompt) action parse_response(response) if action[action] submit_guess: result env.submit(action[parameters][value]) state.history.append({ guess: action[parameters][value], result: result }) state.round 1 if result[result] correct: return {success: True, rounds: state.round} state update_state(state, result) if state.consecutive_failures 3: state reflect_and_adjust(state) return {success: False, rounds: state.round}这个主循环看起来简单但里面有几个关键的控制点。一个是失败计数器用来检测Agent是不是卡住了。另一个是反思触发条件我设的是连续3次失败或者连续5轮没有显著缩小搜索区间。反思的逻辑是让模型回顾之前的决策找出可能的错误模式然后调整策略。4.5 参数选择与调优过程参数调优这块我花了不少时间因为不同的参数组合对Agent的表现影响很大。我主要调了四个参数温度temperature我试了0.0、0.2、0.5、0.8四个值。0.0的时候模型输出非常稳定但有时候会陷入局部最优比如一直猜同一个值。0.8的时候探索性很强但输出格式经常出错。最后选了0.2在稳定性和探索性之间取得了比较好的平衡。最大轮次max_rounds这个取决于搜索空间的大小和反馈的粒度。对于1到100的搜索空间精确反馈下二分法最多7轮就能猜中所以max_rounds设10就够了。但如果是模糊反馈可能需要15到20轮。我最终设的是20留了足够的余量。信息增益的折扣因子在计算期望信息增益的时候我会给远期收益打一个折扣因为轮次越往后不确定性越大。折扣因子设的是0.95意味着每往后一轮收益打95折。这个参数对策略的影响不大但设了之后Agent会更倾向于在早期做信息量大的猜测。失败重试次数工具调用失败后的重试次数我设的是3次。超过3次就触发降级。实测下来大部分失败都是瞬时的重试1到2次就能成功。设3次是为了覆盖偶发的连续失败。调参的过程不是一蹴而就的我是用网格搜索的方式每组参数跑50次模拟然后看平均轮次和成功率。最终选定的参数组合在精确反馈下平均5.2轮猜中模糊反馈下平均12.8轮猜中噪声反馈10%噪声下平均8.5轮猜中。5. 常见问题与排查技巧实录5.1 Agent卡在同一个区间反复猜测怎么办这是最常见的问题之一。表现是Agent连续好几轮都在一个很小的范围内猜来猜去但就是猜不中。原因通常有三个第一反馈有噪声Agent被错误反馈带偏了第二概率分布更新有问题某些桶的概率被错误地置零了第三决策策略陷入了局部最优。排查的时候我会先把状态对象打印出来看概率分布的形状。如果发现概率分布集中在某个错误的区间那基本可以确定是反馈噪声导致的。这时候的解决办法是增加概率平滑的强度给每个桶保留更高的基础概率让Agent有机会跳出错误区间。如果是概率分布看起来正常但Agent还是反复猜同一个值那可能是决策策略的问题。我会检查信息增益的计算逻辑看看是不是某个候选的增益被高估了。有时候是因为反馈模型估计得太乐观导致Agent过度自信。避坑技巧在状态里加一个“最近N轮猜测值”的列表如果发现重复值超过阈值就强制Agent换一个策略比如随机在搜索区间内选一个值打破僵局。5.2 模型输出格式不符合预期怎么处理这个问题在初期特别常见。模型有时候会输出额外的解释文字有时候JSON格式不对有时候字段名写错。我的处理策略是三层解析第一层尝试直接解析JSON。如果成功校验字段是否完整。第二层如果直接解析失败用正则表达式提取JSON片段再解析。第三层如果还是失败就把原始输出和错误信息一起返回给模型让它重新生成。import json import re def parse_response(response: str) - dict: try: return json.loads(response) except json.JSONDecodeError: pass json_match re.search(r\{.*\}, response, re.DOTALL) if json_match: try: return json.loads(json_match.group()) except json.JSONDecodeError: pass return {action: error, raw: response}如果三层都失败了那说明模型的输出确实有问题。这时候我会在下一轮的prompt里加上一个更强的格式约束比如“你必须只输出JSON不要有任何其他文字”。实测下来加了这句话之后格式错误率会大幅下降。5.3 工具调用超时或限流怎么应对工具调用超时是分布式系统的常态尤其是在调用外部API的时候。我的应对策略是指数退避重试。第一次失败后等1秒重试第二次失败后等2秒第三次失败后等4秒。如果三次都失败就触发降级。降级策略取决于具体的工具。对于submit_guess降级方案是切换到本地模拟环境先用模拟结果继续跑等外部环境恢复了再同步状态。对于get_history降级方案是直接从本地状态对象里读历史不走外部调用。还有一个细节是限流处理。如果API返回429状态码说明请求太频繁了。这时候不能简单地重试而是要等更长的时间。我会在重试逻辑里检测429如果遇到429就把退避时间乘以2并且降低后续请求的频率。5.4 常见问题速查表问题现象可能原因排查方法解决方案Agent反复猜同一个值决策策略陷入局部最优打印概率分布和候选增益增加概率平滑强制探索模型输出格式错误Prompt约束不够强检查原始输出加强格式约束三层解析工具调用超时网络问题或API限流查看错误码和响应时间指数退避重试降级方案猜中轮次明显偏多反馈噪声或策略不佳对比理论最优轮次调整信息增益计算增加平滑状态不一致多步操作未原子化检查状态更新逻辑事务化状态更新模型“忘记”历史上下文过长或状态未显式管理检查prompt长度显式状态管理最小上下文5.5 独家避坑经验分享最后分享几个我在这个项目里踩过的坑都是文档里不会写的。第一个坑不要过度依赖模型的“推理能力”。我一开始想让模型自己根据历史反馈推理出目标值的范围结果发现模型经常算错。后来我把区间更新的逻辑放到代码里模型只负责生成候选值准确率立刻上去了。确定性的事情交给代码不确定性的事情交给模型这个分工原则帮我省了很多调试时间。第二个坑反馈信息的呈现方式比反馈本身更重要。同样的反馈“高了”如果我在prompt里写成“你猜的42高了目标值在1到41之间”模型下一轮的猜测质量明显更好。因为模型不需要自己做区间推理直接拿到更新后的区间就行。这个改动看起来很小但效果提升很明显。第三个坑不要忽略冷启动问题。第一轮猜测的时候Agent没有任何历史信息这时候如果让模型自由发挥它可能会猜一个很偏的值。我的做法是在第一轮强制使用二分法的中间值从第二轮开始才让模型参与决策。这样保证了冷启动的稳定性。第四个坑日志要详细但不要冗余。我一开始把每一轮的完整prompt和完整响应都记下来结果日志文件巨大排查的时候反而找不到重点。后来我改成只记录关键信息轮次、猜测值、反馈结果、概率分布的熵、决策耗时。这些信息足够定位大部分问题了。第五个坑测试用例要覆盖边界情况。我一开始只用随机目标值测试后来发现目标值在边界附近比如1或者100的时候Agent的表现明显变差。原因是概率分布在边界处的更新逻辑有bug某些情况下会导致概率不归一化。修复之后边界情况的表现就正常了。所以测试的时候一定要覆盖最小值、最大值、中间值、以及各种反馈模式的组合。这个项目我前前后后跑了大概两周从最初的能跑就行到后来的稳定在5轮左右猜中中间经历了很多次“看起来没问题但实际一跑就崩”的情况。最大的体会是Agent开发不是把模型接上工具就完事了状态管理、错误处理、决策策略这三块才是真正决定成败的地方。模型的能力决定了上限但工程实现决定了下限。把下限做稳了上限才有意义。