1. 项目概述Trace下一代“自动微分”工具如果你用过PyTorch或者TensorFlow对autograd和backward()这两个词一定不陌生。它们构成了现代深度学习训练的基石我们定义一个计算图神经网络输入数据计算损失然后调用loss.backward()框架就会自动计算所有参数的梯度并指导优化器更新。整个过程优雅、自动我们称之为“自动微分”。但你想过没有这个范式能被推广吗我们训练的对象是否只能是那些能用连续、可微函数完美描述的神经网络如果我想训练一个包含if-else分支、字符串操作、甚至调用外部API比如一个大语言模型的复杂AI智能体呢如果我的“损失”不是一个可微的标量而是一段自然语言反馈比如“这个回复不够友好”或者一个编译错误又或者是一个游戏得分呢这就是微软开源的Trace项目要解决的核心问题。它提出了一个大胆的构想将“自动微分”的思想从纯粹的数值计算推广到包含任意Python代码、接受任意形式反馈的通用AI系统优化上。你可以把它理解为面向复合AI系统或AI智能体工作流的“自动微分”工具。想象一下你构建了一个销售客服机器人它的工作流包括理解用户意图、查询数据库、生成回复。传统的做法是你手动设计提示词然后通过A/B测试或者人工评估来迭代优化过程缓慢且不系统。而使用Trace你可以将这个工作流定义为一个可训练的计算图然后提供一个“反馈函数”比如用户满意度评分或者人工标注的“好/坏”评语Trace就能像训练神经网络一样自动地、端到端地优化这个智能体内部的各个可调部分比如提示词、决策逻辑使其输出更符合你的期望。简单来说Trace的核心价值在于它为基于大语言模型LLM构建的、非传统的、不可微的AI系统提供了一套类似于PyTorch的训练框架。让你能用写PyTorch代码的熟悉感去训练和优化一个复杂的AI智能体。2. 核心设计理念与架构拆解要理解Trace为什么能工作我们需要先拆解它的几个核心设计理念这比直接看代码更重要。2.1 从“自动微分”到“生成式优化”传统的自动微分AutoDiff依赖于一个关键数学性质链式法则。它要求图中的每一个操作都是可微的这样梯度才能从输出损失一路“反向传播”回输入参数。然而在基于LLM的智能体中大量操作是离散的、符号化的、不可微的。例如LLM生成文本是一个采样过程if x 0:是一个条件分支str.find()是一个字符串操作。这些操作没有传统意义上的“梯度”。Trace巧妙地绕开了这个限制。它不再追求计算“数值梯度”而是转向了“生成式优化”。其核心思想是执行轨迹捕获当你的Python代码智能体工作流运行时Trace会像调试器一样自动记录下每一个关键操作的“执行轨迹”。这个轨迹不仅包含数据流哪个节点的值变成了什么还包含控制流执行了哪个分支、甚至代码本身调用了哪个函数。反馈传播当你提供一个反馈比如“这个答案不正确”后Trace的优化器如OptoPrime会分析整个执行轨迹。它会逆向思考“为了得到一个‘正确’的反馈轨迹中的哪些决策点即可训练的node或bundle应该被改变应该如何改变”参数更新优化器本身通常也是一个LLM根据反馈和轨迹生成对可训练参数的修改建议。例如它可能会重写一段提示词或者调整一个决策阈值。这个过程不是基于梯度下降而是基于对代码和上下文的理解进行“编辑”或“重写”。所以Trace的backward()方法传播的不是梯度而是“如何改进的指令”。它的step()方法执行的也不是参数 参数 - 学习率 * 梯度而是参数 优化器(参数 轨迹 反馈)。2.2 核心抽象Node, Bundle 与 ModelTrace提供了三个核心的Python装饰器/类来帮你构建可优化的计算图它们的设计非常直观。node计算图的基本单元你可以把node理解为一个“包装盒”里面可以放任何Python对象——整数、字符串、列表、字典甚至一个自定义类的实例。一旦一个对象被node()包装Trace就开始追踪所有对它的操作。from opto.trace import node # 创建一个可训练的参数节点初始值为1 learning_rate node(1, trainableTrue) # 创建一个不可训练的常量节点 base_value node(10) # 进行运算Trace会自动记录这个加法操作 result base_value learning_rate * 2 print(result.data) # 输出12 # 像操作普通列表一样操作node列表 list_node node([1, 2, 3]) list_node.append(node(4))关键在于trainableTrue。这告诉Trace“这个节点的值是可以被优化器修改的。” 在后面的例子中learning_rate就可能被优化器调整。bundle将函数变为可优化模块这是Trace中最强大的抽象。bundle装饰器可以将任何一个普通的Python函数转变为一个“可优化模块”。这个模块内部的逻辑甚至是代码文本都可以成为优化的对象。from opto.trace import bundle bundle(trainableTrue) # 标记这个bundle是可训练的 def decision_logic(score): 根据分数返回决策。 优化器可以修改这个函数的实现 if score 0.5: return approve else: return reject # 像调用普通函数一样使用它 decision decision_logic(node(0.7)) print(decision.data) # 输出”approve“在优化过程中Trace的优化器可能会将decision_logic这个函数的代码从if score 0.5:改成if score 0.3:或者完全重写这个函数。这实现了对“算法逻辑”本身而不仅仅是参数进行优化。model构建复杂的可训练智能体model是一个类装饰器用于构建更复杂的、有状态的智能体。它允许你将多个node和bundle方法组合在一个类里。from opto import trace trace.model class CustomerServiceAgent: def __init__(self): # 定义可训练的系统提示词 self.system_prompt trace.node(You are a helpful assistant., trainableTrue) # 定义可训练的指令节点 self.extraction_instruction trace.node(Extract the customers name and issue., trainableTrue) trace.bundle(trainableTrue) def analyze_sentiment(self, user_message): 分析用户情绪。此方法的具体实现可被优化。 # 这里可以调用LLM优化器可以修改调用方式或后处理逻辑 sentiment trace.operators.call_llm(self.system_prompt, Analyze sentiment of:, user_message) return positive if good in sentiment.lower() else negative def __call__(self, user_query): # 工作流分析情绪 - 提取信息 - 生成回复 sentiment self.analyze_sentiment(user_query) extracted_info trace.operators.call_llm(self.system_prompt, self.extraction_instruction, user_query) # ... 组合最终回复 return final_responsemodel类让你能够以面向对象的方式构建结构清晰、模块化的可训练智能体。2.3 优化器OptoPrime, TextGrad 与 OPROTrace将优化算法抽象出来支持多种“生成式优化器”你可以像在PyTorch中切换SGD和Adam一样切换它们。OptoPrime默认/推荐这是Trace论文中提出的核心优化器。它的特点是利用完整的计算图轨迹进行优化。优化器LLM能够看到从输入到输出的整个执行链条从而做出更全局、更一致的修改决策。优点是优化质量高、相对高效。TextGrad受同名论文启发实现的优化器。它将优化问题视为通过文本反馈进行的“微分”。它可能不会在每一步都利用完整计算图而是更侧重于基于局部反馈进行迭代修正。在某些简单问题上表现良好但在复杂轨迹上可能不如OptoPrime精准。OPRO基于“LLM作为优化器”论文。它不依赖于Trace的计算图而是将优化视为一个黑盒搜索问题。它速度很快尤其适合参数空间较小、反馈定义清晰的问题但缺乏对内部逻辑的理解无法进行精细的代码级优化。选择建议新手或大多数场景直接用OptoPrime它是为Trace量身定制的能最好地发挥框架优势。需要快速原型验证或参数搜索可以尝试OPRO。与TextGrad论文进行对比实验使用TextGrad。from opto.optimizers import OptoPrime, TextGrad, OPRO # 你的可训练模型 my_trainable_model ... # 像PyTorch一样初始化优化器传入模型参数 optimizer OptoPrime(my_trainable_model.parameters()) # optimizer TextGrad(my_trainable_model.parameters()) # optimizer OPRO(my_trainable_model.parameters())3. 从零开始构建并优化你的第一个Trace智能体理论说了这么多我们来动手实现一个经典案例一个语言翻译智能体。这个智能体最初翻译效果不好我们将通过Trace仅用几条“正确/错误”的反馈让它学会如何正确翻译。3.1 问题定义与智能体构建假设我们有一个简单的翻译智能体它接收中文输入输出英文。但它的初始逻辑很糟糕只是简单地在输入后面加上英文单词。我们的目标是通过提供“这个翻译好/不好”的反馈让Trace优化这个智能体内部的提示词和逻辑最终让它输出正确的翻译。import opto from opto import trace from opto.optimizers import OptoPrime # 1. 定义可训练的翻译智能体 trace.model class SimpleTranslator: def __init__(self): # 可训练的系统提示词告诉LLM它的角色 self.system_prompt trace.node(You are a translator. Translate Chinese to English., trainableTrue) # 可训练的翻译指令具体告诉LLM怎么做 self.translation_instruction trace.node(Translate the following text directly without explanation., trainableTrue) def __call__(self, chinese_text): 翻译主函数 # 调用LLM进行翻译。trace.operators.call_llm 是Trace封装的LLM调用器。 # 它会自动记录这次调用并将其纳入计算图。 english_output trace.operators.call_llm( self.system_prompt, self.translation_instruction, fChinese: {chinese_text} ) return english_output # 2. 实例化智能体和优化器 translator SimpleTranslator() optimizer OptoPrime(translator.parameters()) print(初始可训练参数) for name, param in translator.named_parameters(): print(f {name}: {param.data})运行这段代码你会看到两个可训练的node它们目前的值就是我们初始化的字符串。这两个字符串就是我们要优化的“参数”。3.2 定义反馈函数与训练循环接下来我们需要定义一个反馈函数。这个函数模拟了“用户”或“评估标准”对翻译结果的评判。在真实场景中它可以连接人工评估平台、自动化评分工具甚至是另一个LLM裁判。# 3. 定义反馈函数 def get_feedback(prediction, ground_truth): 对比智能体的预测和标准答案给出反馈。 反馈可以是字符串、数字、布尔值等任意形式。 这里我们返回一个字符串描述。 # 简单起见我们进行精确匹配。实际中可以用更复杂的相似度度量。 if prediction.data.strip().lower() ground_truth.lower(): return Translation is correct and accurate. else: return fTranslation is incorrect. You said {prediction.data}, but it should be {ground_truth}. # 4. 准备训练数据 training_data [ (你好世界, Hello, world), (我爱你, I love you), (今天天气很好, The weather is nice today), ] # 5. 训练循环 epochs 5 for epoch in range(epochs): print(f\n Epoch {epoch 1} ) total_correct 0 for chinese, true_english in training_data: # 前向传播智能体进行翻译 optimizer.zero_feedback() # 清除上一轮的反馈累积类似zero_grad try: translation translator(chinese) feedback get_feedback(translation, true_english) is_correct translation.data.strip().lower() true_english.lower() except trace.ExecutionError as e: # 如果执行出错如LLM调用失败反馈为错误 translation e.exception_node feedback Execution failed. is_correct False print(fInput: {chinese}) print(fOutput: {translation.data}) print(fExpected: {true_english}) print(fFeedback: {feedback}) if is_correct: total_correct 1 # 如果正确我们可以选择不进行优化或者给予正向反馈进行强化 # 这里我们简单跳过优化步骤 continue # 反向传播与优化核心步骤 # backward() 接收需要优化的目标节点和反馈信息。 # 优化器会分析导致translation这个结果的整个计算图并结合feedback思考如何改进。 optimizer.backward(translation, feedback) # step() 执行优化。优化器LLM会生成新的参数值即新的提示词并更新模型。 optimizer.step(verboseTrue) # verboseTrue 会打印优化器执行的动作 print(fEpoch {epoch1} Accuracy: {total_correct}/{len(training_data)}) # 如果全部正确提前结束训练 if total_correct len(training_data): print(All translations correct! Training stopped.) break # 6. 查看优化后的参数 print(\n 训练后的参数 ) for name, param in translator.named_parameters(): print(f {name}: {param.data})关键步骤解析optimizer.zero_feedback(): 类比PyTorch的optimizer.zero_grad()用于清除上一轮迭代中累积的反馈信息。在Trace中某些优化器可能支持反馈累积但通常每步都需要清零。translator(chinese): 这就是前向传播。Trace在背后记录了所有node和bundle的调用构建了完整的计算图。optimizer.backward(translation, feedback): 这是Trace的“反向传播”。它并不计算梯度而是将translation这个节点和feedback这个字符串或其它形式反馈交给优化器。优化器会回溯translation是如何计算出来的并思考“根据这个反馈是哪个node或bundle导致了问题应该如何修改它们”optimizer.step(verboseTrue): 优化器执行更新。对于OptoPrime它可能会调用配置的LLM如GPT-4将计算图、当前参数值和反馈一起输入要求LLM输出修改后的新参数值。verboseTrue会让你在控制台看到类似[OptoPrime] Updating parameter system_prompt...的日志。3.3 实战运行与结果分析当你运行上述代码时需要配置好LLM API密钥后文会讲可能会观察到类似下面的过程初始可训练参数 system_prompt: You are a translator. Translate Chinese to English. translation_instruction: Translate the following text directly without explanation. Epoch 1 Input: ‘你好世界’ Output: ‘你好世界 Hello, world’ # 初始逻辑不好只是追加 Feedback: Translation is incorrect. You said ‘你好世界 Hello, world’, but it should be ‘Hello, world’. [OptoPrime] Analyzing trace for node ‘translation’... [OptoPrime] Feedback: Translation is incorrect... [OptoPrime] Proposed update to ‘translation_instruction’: “Output only the English translation, nothing else.” Input: ‘我爱你’ Output: ‘I love you’ # 优化后第一次就对了 Feedback: Translation is correct and accurate. Input: ‘今天天气很好’ Output: ‘The weather is nice today’ # 也对了 ... 训练后的参数 system_prompt: You are a professional Chinese-to-English translator. Provide accurate and concise translations. translation_instruction: Output only the English translation, without any additional text or the original Chinese.可以看到Trace的优化器OptoPrime不仅修改了translation_instruction让它从“直接翻译”变得更具体为“只输出英文翻译”甚至还优化了system_prompt使其角色描述更专业。这就是生成式优化的威力它直接理解和修改“程序”的语义层。实操心得反馈的设计至关重要在这个简单例子中我们用了精确匹配和字符串反馈。在实际项目中反馈设计是门艺术。过于笼统的反馈如“不好”可能让优化器不知所措。尽可能提供具体、可行动的反馈。例如错误反馈“The translation is too verbose. It should be more concise like ‘Hello, world’.”正确反馈“Good. The translation is accurate and natural.”好的反馈能极大加速优化过程减少优化器LLM的调用次数也就是降低成本。4. 深入原理Trace如何运作与高级用法理解了基本流程后我们深入看看Trace内部的关键机制以及一些更高级的用法。4.1 计算图追踪与可视化Trace的核心是动态构建并追踪计算图。你可以随时将这个图可视化这对于调试复杂工作流极其有用。from opto.trace import node # 构建一个简单计算图 a node(5, trainableTrue, name”input_a”) b node(3, name”constant_b”) c a * b d c node(10, name”constant_10”) result d / node(2, name”constant_2”) # 方法1在backward时可视化 # 这会生成一个文本形式的图显示在控制台 result.backward(“maximize result”, visualizeTrue, print_limit50) # 方法2导出为DOT格式可用Graphviz渲染 graph_dot result._trace.to_dot() with open(“computation_graph.dot”, “w”) as f: f.write(graph_dot) # 然后在命令行使用 dot -Tpng computation_graph.dot -o graph.png 生成图片可视化输出能清晰展示node之间的依赖关系、操作类型帮助你确认你的工作流是否被正确追踪。对于排查“为什么这个参数没有被优化”之类的问题非常有效。4.2 处理复杂控制流与错误现实中的智能体充满if-else、循环和可能失败的操作如网络调用。Trace能很好地处理这些情况。from opto import trace trace.bundle(trainableTrue) def safe_divide(x, y): 一个安全的除法如果除数为0则返回一个很大的数。这个逻辑可以被优化。 if y.data 0: # 注意比较的是 .data 属性 return trace.node(1e6) # 返回一个错误值 else: return x / y trace.model class RobustAgent: def __init__(self): self.threshold trace.node(0.5, trainableTrue) # 可训练的决策阈值 def __call__(self, input_value): # 一个包含条件分支的工作流 processed safe_divide(input_value, trace.node(2)) # 根据阈值做决策 decision trace.operators.call_llm( trace.node(“You are a decision maker.”), f”The processed value is {processed.data}. Is it high?”, f”Answer only ‘yes’ or ‘no’.” ) # 模拟一个基于决策的行动 final_output trace.node(“default”) if decision.data.lower().strip() “yes”: final_output trace.node(“Action: ACCEPT”) else: final_output trace.node(“Action: REJECT”) return final_output # 训练时需要处理可能的执行错误 agent RobustAgent() optimizer OptoPrime(agent.parameters()) try: output agent(trace.node(10)) feedback “good” if “ACCEPT” in output.data else “bad” optimizer.backward(output, feedback) except trace.ExecutionError as e: # 如果计算图中任何一步出错如LLM调用超时会抛出ExecutionError print(f”Execution failed at node: {e.exception_node}”) # 你可以选择对错误节点进行优化告诉优化器“这里出错了请修复” optimizer.backward(e.exception_node, “This step caused an execution error. Fix it.”) finally: optimizer.step()关键点trace.ExecutionError是Trace中表示执行错误的异常。e.exception_node包含了出错的那个节点。你可以对这个节点进行backward让优化器去修复导致错误的逻辑。在bundle函数内部你需要通过.data属性来访问node的实际值进行比较或操作。直接使用node对象进行比较会比较对象本身而不是其值。4.3 集成外部工具与API智能体常常需要调用外部工具。Trace通过node包装和自定义bundle可以轻松地将外部调用纳入优化范围。import requests from opto import trace trace.bundle(trainableFalse) # 通常外部API调用本身不可训练但对其输入输出的处理可以 def call_weather_api(city_name_node): 调用外部天气API。city_name_node是一个可训练的node。 city_name city_name_node.data # 假设的API response requests.get(f”https://api.weather.com/v1/{city_name}”) if response.status_code 200: data response.json() return trace.node(data[“temperature”]) # 返回一个包含温度的node else: # API调用失败返回一个错误标记节点 return trace.node(None, metadata{“error”: “API call failed”}) trace.model class WeatherReporter: def __init__(self): # 可训练如何构建查询城市的字符串 self.query_template trace.node(“Get weather for {}”, trainableTrue) def __call__(self, city): # 使用可训练的模板构建查询 query self.query_template.data.format(city) # 调用外部API这个过程被追踪 temperature_node call_weather_api(trace.node(query)) # 根据温度生成报告这个bundle可训练 report self._generate_report(temperature_node) return report trace.bundle(trainableTrue) def _generate_report(self, temp_node): if temp_node.data is None: return trace.node(“Failed to fetch weather data.”) # 优化器可以修改这个报告生成的逻辑和措辞 if temp_node.data 25: return trace.node(f”It’s a hot day with {temp_node.data}°C.”) else: return trace.node(f”It’s a cool day with {temp_node.data}°C.”) # 训练这个WeatherReporter优化器可能会 # 1. 修改 query_template使其更符合API的格式。 # 2. 修改 _generate_report 的逻辑和文本使其更人性化。通过这种方式Trace的优化可以渗透到智能体的每一个环节包括它如何与外部世界交互。5. 环境配置、性能调优与避坑指南要让Trace跑起来并跑得好需要一些实际的配置和技巧。5.1 LLM后端配置与API管理Trace默认使用LiteLLM作为LLM后端它统一了众多AI供应商的API。配置非常简单# 在终端中设置环境变量 export OPENAI_API_KEY”sk-your-openai-key” export ANTHROPIC_API_KEY”your-anthropic-key” export TRACE_LITELLM_MODEL”gpt-4o” # 设置默认模型# 或者在Python脚本中设置 import os os.environ[“OPENAI_API_KEY”] “sk-your-openai-key” os.environ[“TRACE_LITELLM_MODEL”] “gpt-4o” from opto import trace # 现在Trace会使用gpt-4o进行所有优化和LLM调用模型选择建议优化器OptoPrime/TextGrad强烈建议使用能力最强的模型如GPT-4o或Claude 3.5 Sonnet。优化任务需要模型具备强大的推理、代码理解和指令遵循能力。GPT-3.5或更弱的模型可能无法产生有效的优化步骤。智能体中的LLM调用trace.operators.call_llm可以根据任务复杂度和成本选择。对于简单的文本处理gpt-3.5-turbo可能就足够了。对于复杂的推理仍需强模型。重要警告关于GPT-4o版本Trace的优化器严重依赖LLM的结构化输出如JSON。早期版本的gpt-4o-2024-05-13在遵循JSON格式指令上存在严重问题会导致优化失败。务必使用gpt-4o-2024-08-06或更新的版本。你可以在LiteLLM中指定完整版本号export TRACE_LITELLM_MODEL’gpt-4o-2024-08-06’。5.2 成本控制与优化策略使用Trace进行优化本质上是反复调用昂贵的LLM尤其是GPT-4o。成本可能快速上升。以下是一些控制成本的策略精简计算图只对真正需要优化的部分使用trainableTrue。不必要的可训练节点会增大优化器的搜索空间和上下文长度增加每次step()的成本和难度。设计高效的反馈一条清晰、具体的反馈可能比十条模糊的反馈更有效。在backward()时尽量提供能直接指向问题根源的反馈信息。设置合理的训练轮次Epoch像训练神经网络一样监控验证集如果有的話上的表现避免过拟合和无效迭代。通常一个复杂智能体在5-10个epoch内就会有明显提升。利用缓存LiteLLM支持对话缓存。对于相同的输入Trace的LLM调用可能会被缓存这能在开发调试时节省成本。确保你的LiteLLM缓存是开启的默认通常是开启的。从小处开始先用一个非常小的子任务或单个数据点进行优化验证工作流和反馈机制是否有效然后再扩展到完整数据集。5.3 常见问题与排查技巧问题1optimizer.step()后参数没有任何变化检查点确保你的node或bundle设置了trainableTrue。检查反馈optimizer.backward(target_node, feedback)中的feedback是否提供了有效信息过于模糊或矛盾的反馈可能导致优化器无法行动。尝试将反馈改为更具体、可操作的描述。检查优化器日志设置optimizer.step(verboseTrue)查看优化器是否识别出了可训练参数并尝试更新。如果日志显示No trainable parameters affected说明当前的计算图路径没有经过你设置的可训练参数需要检查你的工作流逻辑。检查LLM调用确认你的API密钥和模型设置正确并且LLM调用没有因网络或配额问题而失败。查看是否有相关的错误日志。问题2执行过程中抛出trace.ExecutionError定位错误节点捕获异常后打印e.exception_node。这个节点包含了出错的操作和信息。检查节点数据出错往往是因为某个node的.data不符合预期如None、类型错误。在关键的bundle函数中加入print语句或使用trace.operators.debug(node)来输出中间值。处理外部依赖如果错误来自外部API调用如超时、返回格式错误你需要在bundle中做好异常处理并返回一个代表错误的特殊node然后在训练循环中针对这种错误提供反馈如“API调用失败请调整查询参数或添加重试逻辑”。问题3优化过程非常慢计算图过大Trace尤其是OptoPrime会将整个计算图上下文发送给LLM。如果图过于复杂节点超过几百个会导致上下文极长增加API调用时间和成本。考虑重构工作流将其拆分成多个独立的、可分别优化的子model。使用更快的模型对于优化器可以尝试claude-3-haiku或gpt-3.5-turbo对于简单问题来提速但效果可能会打折扣。切换到OPRO如果你的优化问题主要是搜索一组离散参数如几个提示词而不是修改复杂逻辑可以尝试OPRO优化器它通常更快。问题4优化结果不稳定时好时坏LLM的随机性这是使用LLM作为优化核心的固有挑战。为了提升稳定性设置温度Temperature在优化器调用LLM时尝试设置较低的温度如0.1或0。这需要在Trace更深层的配置中设置可能涉及修改LiteLLM的调用参数。多次采样与选择实现一个简单的“集束搜索”。运行多次optimizer.step()每次可能产生不同的更新方案然后用一个验证集评估哪个更新方案最好选择那个方案。更严格的反馈提供更精确、约束性更强的反馈减少优化器的发挥空间。6. 进阶应用场景与项目构思掌握了Trace的基础和技巧后你可以尝试以下更有挑战性的项目场景一游戏AI智能体优化项目构建一个玩简单文字游戏如猜数字、21点的智能体。Trace应用将智能体的决策逻辑何时叫牌、何时停止用bundle定义。反馈是每局的游戏得分。挑战与技巧反馈稀疏只有最终得分。可以设计中间奖励如“叫牌后点数未爆”给予小奖励或者让优化器分析整局游戏轨迹来学习策略。场景二代码生成与修复工作流项目一个根据自然语言描述生成SQL查询的智能体。Trace应用model包含1) 理解用户意图的bundle2) 生成SQL草稿的bundle3) 执行SQL并解释结果的bundle。反馈使用数据库的语法错误作为反馈“SQL语法错误缺少FROM子句”或用执行结果与预期是否匹配作为反馈。优势Trace可以端到端地优化从“理解”到“生成”的整个链条而不仅仅是优化最后的SQL生成提示词。场景三多智能体协作系统项目模拟一个软件团队有项目经理、开发、测试等角色共同完成一个任务。Trace应用为每个角色定义一个model类。它们之间的交互对话、传递工件构成一个更大的计算图。反馈最终产物的质量如代码能否通过测试、文档是否完整。高级用法你可以只优化某个角色的行为如项目经理的任务分解指令也可以同时优化所有角色。Trace能清晰地展示出某个角色的行为变化如何通过交互影响最终结果。场景四机器人任务规划项目让一个模拟机器人完成“收拾桌子”的任务。Trace应用将机器人的感知、规划、动作序列生成定义为可训练的bundle。反馈任务完成度通过模拟器检测、动作效率、是否碰撞。核心这里的“参数”可能是自然语言指令“先拿起杯子再拿起盘子”优化器通过尝试不同的指令序列找到最高效、最安全的那个。Trace的真正威力在于它将AI系统的开发从“手工提示工程”和“碎片化调试”变成了一个可编程、可自动化、可端到端优化的工程流程。你不再需要猜测是哪个提示词出了问题而是定义一个目标反馈函数然后让系统自己去探索和修复。这无疑是构建下一代可靠、强大AI智能体的关键一步。