Prompt版本管理:用Git管理提示词的团队协作方案

为什么Prompt需要版本管理 在团队协作的AI项目中,Prompt是最频繁变更且影响面最大的"配置文件"。一个措辞的微调可能导致模型行为巨变——这和传统代码变更的风险量级完全不同。没有版本管理,你将面对: “谁改了这个prompt?什么时候改的?为什么?” “改了之后效果是变好还是变差?” “如何让多个开发者的prompt变更不冲突?” “如何回滚到已知良好的版本?” 答案是Git——但需要针对Prompt特性做专门设计。 Prompt仓库目录结构 推荐结构 prompt-repo/ ├── prompts/ # 所有prompt定义 │ ├── customer-service/ │ │ ├── router.prompt.yaml # 意图路由prompt │ │ ├── responder.prompt.yaml # 回复生成prompt │ │ └── summary.prompt.yaml # 对话摘要prompt │ ├── extraction/ │ │ └── entity-extract.prompt.yaml │ └── _shared/ # 共享组件 │ ├── system-base.yaml │ └── safety-rules.yaml ├── tests/ # 测试用例 │ ├── golden-sets/ │ │ ├── customer-service-golden.json │ │ └── extraction-golden.json │ └── unit/ │ └── test_template_render.py ├── eval/ # 评测脚本 │ ├── evaluator.py │ └── metrics.py ├── .prompt-lint.yml # lint规则 └── pyproject.toml Prompt文件格式 采用YAML定义prompt元数据,内容与元信息分离: ...

2026-07-29 · 3 min · 562 words · 硅基 AGI 探索者

Prompt工程化:从单次提示到可维护的Prompt管理系统

从"调prompt"到"工程化prompt" 大多数开发者的Prompt工作流起初是这样的:在Playground里反复调试,找到效果好的版本后复制粘贴到代码里。这种方式在原型阶段够用,但一旦进入生产环境,就会暴露一系列问题: prompt散落在代码各处,修改困难 无法追踪历史变更 无法对比不同版本的效果 无法在不同模型间迁移 Prompt工程化就是解决这些问题的系统性方法论。 Prompt模板引擎 模板分离原则 将prompt从代码中剥离,使用模板引擎管理。核心思路与后端的view模板一致: from jinja2 import Environment, FileSystemLoader import yaml import json class PromptTemplate: def __init__(self, template_dir: str): self.env = Environment( loader=FileSystemLoader(template_dir), trim_blocks=True, lstrip_blocks=True ) self.env.filters['to_json_schema'] = lambda x: json.dumps(x, ensure_ascii=False) def render(self, template_name: str, **kwargs) -> str: template = self.env.get_template(template_name) return template.render(**kwargs) # 模板文件: templates/summarizer.jinja2 # 你是一个专业摘要生成器。 # 输入文档:{{ document }} # 要求:生成{{ max_words }}字以内的摘要 # 输出格式:{{ output_format | to_json_schema }} 分层模板架构 templates/ ├── system/ # 系统级prompt │ ├── base_assistant.jinja2 │ └── safety_rules.jinja2 ├── tasks/ # 任务级prompt │ ├── summarizer.jinja2 │ ├── extractor.jinja2 │ └── classifier.jinja2 └── components/ # 可复用片段 ├── few_shot.jinja2 ├── output_format.jinja2 └── context_block.jinja2 通过include实现模块化组合: ...

2026-07-29 · 2 min · 411 words · 硅基 AGI 探索者

Prompt工程的科学方法论:从经验到系统化

Prompt工程不是玄学 很多人认为Prompt工程就是"试不同的话术看哪个效果好"。这是误解。好的Prompt工程是系统工程——有方法论、有评估标准、有优化路径。 第一原则:明确目标 写Prompt之前先问自己:我要模型输出什么?质量的衡量标准是什么? 常见任务类型 信息提取:从文本中提取结构化数据 内容生成:生成文本/代码/分析报告 推理决策:逻辑推理/分类/判断 格式转换:翻译/摘要/格式化 每种类型的Prompt设计策略完全不同。信息提取追求精确,内容生成追求创意,推理决策追求严谨。 结构化Prompt框架 CREATE框架 Context:背景信息(你是谁,在什么场景) Role:角色定义(专家/分析师/审查者) Expectation:期望输出(格式/内容要求) Action:具体任务(做什么) Tone:语气风格(正式/轻松/专业) Examples:示例(Few-Shot) 示例 [Context] 你是一位资深的安全工程师,正在审查一个PR。 [Role] 你以严谨著称,不放过任何安全风险。 [Action] 审查以下代码变更,识别: 1. 潜在的安全漏洞(SQL注入、XSS、CSRF等) 2. 敏感信息泄露 3. 权限控制缺陷 [Expectation] 输出JSON格式: { "severity": "high/medium/low", "issue": "问题描述", "suggestion": "修复建议" } [Tone] 专业、简洁、直接 [Examples] 输入: const query = `SELECT * FROM users WHERE id=${req.query.id}` 输出: {"severity":"high","issue":"SQL注入风险","suggestion":"使用参数化查询"} Few-Shot策略 示例数量 0-shot:简单、明确的任务 1-shot:需要格式示范 3-5 shot:需要模式引导(平衡效果和成本) 5 shot:过度依赖示例可能限制创造力 示例选择 静态选择:手工挑选最有代表性的示例 动态选择:根据当前输入,检索语义相似的示例(类似RAG) 多样性选择:覆盖不同类型/难度的示例 示例顺序 Few-shot的效果对示例顺序敏感。经验法则: 简单→复杂排列 相关示例放在后面(近因效应) 前面放多样性示例 思维链推理 CoT(Chain of Thought) 让模型"想一想再回答"。将推理过程显式化: Q: 一个商店有23个苹果,卖出17个,又进了12个,还有多少? A: 让我们一步步算: 1. 初始有23个苹果 2. 卖出17个:23 - 17 = 6 3. 又进了12个:6 + 12 = 18 答案:18个 适用场景 CoT对以下场景特别有效: ...

2026-07-16 · 1 min · 174 words · 硅基 AGI 探索者

Prompt工程进阶:思维链、自一致性与推理增强技术

超越零样本的推理增强 Prompt工程已从简单的指令编写进化为一门系统化的方法论。在需要复杂推理的任务中,恰当的推理增强技术可以将模型准确率提升30-50%。 思维链(Chain-of-Thought) 基本CoT 思维链的核心思想是让模型"展示推理过程"。通过在prompt中加入"让我们一步步思考"或提供推理示例: Q: 一个商店有23个苹果,卖了17个后又进了8个,现在有多少苹果? A: 让我们一步步思考。 初始数量:23 卖出17个后:23 - 17 = 6 又进了8个后:6 + 8 = 14 答案:14 CoT对数学推理、逻辑推理和多步规划任务效果显著。在GSM8K数学基准上,CoT将GPT-4的准确率从约75%提升到92%。 Zero-shot CoT 最简单的CoT只需在prompt末尾添加: 让我们一步步思考。 这五个字的魔力在于:它激活了模型在预训练阶段学到的"推理模式",使模型生成中间推理步骤而非直接跳到答案。 Few-shot CoT 提供2-4个带有推理过程的示例,效果更好但消耗更多token。关键是示例的推理过程要正确且简洁——过长的推理链反而会降低性能。 自一致性(Self-Consistency) 核心思想 CoT的一个问题是:同一条推理路径可能系统性偏向错误答案。自一致性通过生成多条推理路径并投票选择最一致的答案: def self_consistency(prompt, n_samples=5, temperature=0.7): responses = [] for _ in range(n_samples): response = llm.generate( prompt + "\n让我们一步步思考。", temperature=temperature # 较高温度增加多样性 ) answer = extract_answer(response) responses.append(answer) # 多数投票 from collections import Counter most_common = Counter(responses).most_common(1)[0] return most_common[0] 在GSM8K上,自一致性将准确率从92%进一步提升到96%+。代价是推理成本增加5倍。 采样策略 温度:0.5-0.8之间最佳,太低缺乏多样性,太高推理质量下降 采样数:5-10个样本是性价比最优区间 停止条件:如果前3个答案一致,可以提前停止 思维树(Tree-of-Thought) 核心思想 CoT是线性推理,ToT将推理过程组织为树形结构,支持分支探索和回溯: class ThoughtNode: def __init__(self, thought, parent=None): self.thought = thought self.parent = parent self.children = [] self.value = 0 评估值 self.visited = False def tree_of_thought(problem, max_depth=4, branching=3): root = ThoughtNode(problem) frontier = [root] for depth in range(max_depth): next_frontier = [] for node in frontier: # 生成branching个可能的下一步思考 thoughts = generate_thoughts(node, n=branching) for thought in thoughts: child = ThoughtNode(thought, parent=node) # 评估这个思考方向的价值 child.value = evaluate_thought(thought, problem) node.children.append(child) next_frontier.append(child) # 保留最优的节点继续探索(束搜索) frontier = sorted(next_frontier, key=lambda n: n.value, reverse=True)[:branching] # 回溯最优路径 return trace_best_path(root) 适用场景 ToT在以下场景中明显优于CoT: ...

2026-07-16 · 2 min · 314 words · 硅基 AGI 探索者

从Chain-of-Thought到Tree-of-Thought全面解析

从Chain-of-Thought到Tree-of-Thought全面解析 推理能力是衡量AI智能水平的核心指标。从GPT-3时代的"直觉式回答"到2026年的多路径探索推理,大模型的推理范式经历了几次重要跃迁。本文将系统梳理从Chain-of-Thought到Tree-of-Thought的完整演进脉络。 Chain-of-Thought:让模型"展示推理过程" 核心思想 CoT的洞察看似简单——让模型在给出答案前先输出推理步骤。但这个简单的改变带来了巨大的效果提升。在GSM8K数学推理基准上,CoT将准确率从17.7%提升到58.1%。 CoT的深层原理是:大模型的每个token生成都消耗相同的计算量。“先想后说"本质上是给模型更多的计算预算来处理复杂问题。如果模型直接输出答案,它只用了一个forward pass的计算量。如果模型先输出5步推理再给答案,它用了5倍的计算量。 CoT的三种触发方式 Zero-shot CoT:在Prompt末尾加"Let’s think step by step”。最简单但效果不稳定。 Few-shot CoT:提供几个带推理过程的示例。效果好但需要精心设计示例。 Auto-CoT:让模型自己生成推理示例,减少人工设计。2026年的主流做法是结合few-shot和auto方式,用少量高质量种子示例引导自动生成。 CoT的局限 CoT本质是线性推理——从A推导到B,从B推导到C。但人类思考复杂问题时,往往会探索多条路径,发现走不通就回退重来。CoT没有这种"探索-回退"能力,一旦走上错误的推理路径,会一路错到底。 Self-Consistency:多路径投票 Self-Consistency是对CoT的第一个重要改进。核心思想:对同一个问题让模型生成多条独立的推理链,然后通过投票选择最一致的答案。 这个方法利用了一个关键洞察:正确的推理路径可能只有一条,但正确的答案可能由多条路径到达。通过多次采样并投票,正确答案获得多数票的概率显著提升。 实践效果:在GSM8K上从CoT的58.1%提升到74.4%。代价是推理成本增加N倍(N为采样次数,通常5-20)。 Self-Consistency的局限是它只对有唯一正确答案的问题有效。对于开放性问题(如"最好的方案是什么"),投票机制难以定义。 Tree-of-Thought:树形搜索推理 核心思想 ToT将推理过程建模为一棵搜索树。每个节点是一个"思考状态"(thought),模型从根节点出发,在每个节点生成多个候选的下一步思考,评估每个候选的质量,选择最优的继续探索。 这和CoT的本质区别是:CoT是一条链,ToT是一棵树。树结构允许模型: 在关键决策点探索多个选项 评估每个选项的前景 放弃不好的路径,回溯到好的分支 深度优先或广度优先搜索 ToT的工程实现 标准的ToT流程包含四个步骤: Thought Decomposition:将问题分解为中间思考步骤 Thought Generation:在每个状态生成多个候选下一步 State Evaluation:评估每个候选状态的前景 Search:使用BFS或DFS搜索最优路径 状态评估是ToT最关键也最有挑战的环节。评估方法有两种:数值评分(让模型对状态打1-10分)和排序比较(让模型比较两个状态哪个更好)。实践中,排序比较比数值评分更稳定。 ToT的效果与代价 ToT在复杂推理任务上的效果显著。在创意写作(24点游戏)等需要前瞻和回溯的任务上,ToT大幅超越CoT。但它有一个显而易见的代价——计算量巨大。ToT需要O(b×d)次推理调用,其中b是分支因子,d是搜索深度。一个典型配置b=5, d=3,意味着15次推理调用。 这使ToT在实际应用中需要权衡:简单问题不值得用ToT,复杂问题用ToT可能太慢。我们在硅基AGI平台中使用"自适应推理深度"策略——先用CoT尝试,如果置信度低再升级到ToT。 Graph-of-Thought:推理的图结构 超越树结构 GoT将推理过程从树结构扩展到图结构。核心动机是:不同推理路径之间可能有交叉和合并。在树结构中,两条路径一旦分离就不再交汇;在图结构中,路径可以合并。 一个具体场景:解决问题A需要同时考虑因素B和因素C。CoT会先分析B再分析C;ToT可能把B和C作为两个分支;但GoT允许在分析B的过程中发现与C相关的结论,并将这个结论合并到C的分支中。 知识图谱融合 GoT的一个有前途的方向是将推理图与外部知识图谱融合。推理过程中生成的中间结论作为节点加入知识图谱,后续推理可以直接引用这些结论。这类似于人类"把已经得出的结论记下来,在后面的推理中使用"。 演进趋势:从固定范式到自适应推理 2026年的最新趋势是放弃固定的推理范式,让模型自适应选择推理策略: ReAct:推理+行动交织 ReAct让推理和工具调用交织进行。模型可以先推理"我需要查一下这个数据",然后调用工具获取数据,再基于结果继续推理。这种"边想边做"的模式更接近人类解决问题的实际方式。 Reflexion:带反思的迭代推理 Reflexion在推理完成后增加一个"反思"步骤——模型评估自己的推理过程,识别可能的错误,然后基于反思重新推理。这种"失败-反思-重试"的循环能显著提升复杂任务的成功率。 LATS:语言Agent树搜索 LATS将ToT的思想扩展到Agent场景。搜索树的每个节点不只是一个思考状态,而是一个完整的Agent状态(包括思考、观察、行动)。这使搜索能在更大的行动空间中进行,适合需要多步骤决策的复杂任务。 推理范式的选择指南 基于我们的实践经验,不同场景推荐不同推理策略: 问题类型 推荐策略 理由 简单事实问答 直接回答 CoT反而可能引入错误 数学推理 CoT + Self-Consistency 多路径投票降低单链错误 逻辑推理 CoT 结构化推理足够 创意问题解决 ToT 需要探索多个方向 多步Agent任务 ReAct + Reflexion 需要行动和反思 复杂规划 LATS 大空间搜索 结语 从CoT到ToT的演进,本质是从"线性思考"到"结构化搜索"的范式升级。大模型不只是一个好的语言生成器,它还是一个不完美的推理器——通过外部化的推理结构(链、树、图),我们可以补偿模型自身推理能力的不足。2026年的前沿已经从"让模型更好地推理"转向"设计更好的推理结构来放大模型的推理能力"。 ...

2026-07-13 · 1 min · 91 words · 硅基 AGI 探索者

从Zero-shot到Few-shot:提示工程的进化

从Zero-shot到Few-shot:提示工程的进化 提示工程是大模型时代最具性价比的技术投资。一个精心设计的prompt可以让中等模型的表现超越更大模型在糟糕prompt下的表现。从Zero-shot到Few-shot再到各种高级提示技术,这一领域的进化速度令人瞩目。 Zero-shot:最简形式 Zero-shot是提示工程的原点——不给任何示例,直接让模型回答问题。GPT-3论文最令人震撼的发现就是大模型在zero-shot设置下展现出惊人的能力。 Zero-shot适用于简单的事实问答、文本分类等任务。“判断以下评论是正面还是负面:这家餐厅服务很差”——对于这种简单任务,zero-shot就够了。 但zero-shot在复杂任务上往往不稳定。当你要求模型按特定格式输出、执行多步推理、或遵循复杂的业务规则时,没有示例引导的输出常常偏离预期。 Few-shot:示例驱动的学习 Few-shot通过在prompt中提供少量示例来引导模型的行为。这些示例起到了"格式模板"和"推理模式"的双重作用。 Few-shot的效果提升是显著的。在我们的实践中,对于一个信息抽取任务,zero-shot的F1为0.65,而5-shot的F1提升到0.82。提升不仅来自格式规范,更来自示例中隐含的推理模式。 示例选择的艺术 Few-shot的关键问题是:选择哪些示例?早期实践者随意挑选几个,但很快发现示例选择对效果影响巨大。几个原则: 多样性优先:示例应覆盖不同的输入模式,而非相似案例的重复。多样性帮助模型泛化,而非记忆特定模式。 难度代表性:示例应包含容易和困难的案例。全选简单案例会让模型低估任务难度,全选困难案例则可能让模型过度复杂化简单输入。 动态选择:根据当前输入动态选择最相关的示例,而非固定使用同一组。这就是Dynamic Few-shot的思路——用检索器为每个输入找到最相似的k个示例。 思维链:推理的飞跃 Chain-of-Thought(CoT)是提示工程的里程碑式突破。核心思想:让模型在给出答案前先展示推理过程。 CoT的魔力在于它几乎不增加任何成本——只是在prompt中加一句"让我们一步一步思考"或在示例中展示推理过程。但效果是惊人的:在GSM8K数学推理基准上,CoT让准确率从17.7%跃升到58.1%。 CoT为什么有效?一种解释是它迫使模型将复杂推理分解为多个简单步骤,每步的计算量在模型能力范围内。另一种解释是中间推理token为模型提供了额外的"计算空间"。 CoT的变体 Zero-shot CoT:不需要示例,只需在问题后加"Let’s think step by step"。简单到不可思议,但确实有效。 Self-Consistency:生成多条推理路径,通过投票选择最终答案。代价是多次推理,但准确率提升显著。 Tree-of-Thoughts:将推理过程组织为树结构,支持回溯和分支探索。在需要搜索和规划的任务上表现优异。 2026年的提示工程 进入2026年,提示工程已经远远超出了"写个好prompt"的范畴: 程序化提示:将prompt编写为结构化程序,包含条件分支、循环、变量替换。这使得prompt可以适应不同的输入情况,而非一刀切。 自动提示优化:使用优化算法(如梯度下降或进化算法)自动搜索最优prompt。代表工作如APE、OPRO等,已经在多个任务上超越人工设计的prompt。 多Agent提示编排:多个Agent各司其职,通过prompt定义角色和交互协议。提示工程从单个prompt的设计扩展到Agent群体的交互设计。 结语 提示工程是大模型应用中最"杠杆"的技术——投入小,影响大。但需要注意的是,提示工程不是万能药。在模型能力不足的领域,再精妙的prompt也无法突破模型本身的能力边界。提示工程和模型能力的提升是互补的:更好的prompt释放模型的潜力,更强的模型让prompt的要求更低。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 37 words · 硅基 AGI 探索者

从Zero-shot到Few-shot:提示工程的进化

从Zero-shot到Few-shot:提示工程的进化 提示工程是大模型时代最具性价比的技术投资。一个精心设计的prompt可以让中等模型的表现超越更大模型在糟糕prompt下的表现。从Zero-shot到Few-shot再到各种高级提示技术,这一领域的进化速度令人瞩目。 Zero-shot:最简形式 Zero-shot是提示工程的原点——不给任何示例,直接让模型回答问题。GPT-3论文最令人震撼的发现就是大模型在zero-shot设置下展现出惊人的能力。 Zero-shot适用于简单的事实问答、文本分类等任务。“判断以下评论是正面还是负面:这家餐厅服务很差”——对于这种简单任务,zero-shot就够了。 但zero-shot在复杂任务上往往不稳定。当你要求模型按特定格式输出、执行多步推理、或遵循复杂的业务规则时,没有示例引导的输出常常偏离预期。 Few-shot:示例驱动的学习 Few-shot通过在prompt中提供少量示例来引导模型的行为。这些示例起到了"格式模板"和"推理模式"的双重作用。 Few-shot的效果提升是显著的。在我们的实践中,对于一个信息抽取任务,zero-shot的F1为0.65,而5-shot的F1提升到0.82。提升不仅来自格式规范,更来自示例中隐含的推理模式。 示例选择的艺术 Few-shot的关键问题是:选择哪些示例?早期实践者随意挑选几个,但很快发现示例选择对效果影响巨大。几个原则: 多样性优先:示例应覆盖不同的输入模式,而非相似案例的重复。多样性帮助模型泛化,而非记忆特定模式。 难度代表性:示例应包含容易和困难的案例。全选简单案例会让模型低估任务难度,全选困难案例则可能让模型过度复杂化简单输入。 动态选择:根据当前输入动态选择最相关的示例,而非固定使用同一组。这就是Dynamic Few-shot的思路——用检索器为每个输入找到最相似的k个示例。 思维链:推理的飞跃 Chain-of-Thought(CoT)是提示工程的里程碑式突破。核心思想:让模型在给出答案前先展示推理过程。 CoT的魔力在于它几乎不增加任何成本——只是在prompt中加一句"让我们一步一步思考"或在示例中展示推理过程。但效果是惊人的:在GSM8K数学推理基准上,CoT让准确率从17.7%跃升到58.1%。 CoT为什么有效?一种解释是它迫使模型将复杂推理分解为多个简单步骤,每步的计算量在模型能力范围内。另一种解释是中间推理token为模型提供了额外的"计算空间"。 CoT的变体 Zero-shot CoT:不需要示例,只需在问题后加"Let’s think step by step"。简单到不可思议,但确实有效。 Self-Consistency:生成多条推理路径,通过投票选择最终答案。代价是多次推理,但准确率提升显著。 Tree-of-Thoughts:将推理过程组织为树结构,支持回溯和分支探索。在需要搜索和规划的任务上表现优异。 2026年的提示工程 进入2026年,提示工程已经远远超出了"写个好prompt"的范畴: 程序化提示:将prompt编写为结构化程序,包含条件分支、循环、变量替换。这使得prompt可以适应不同的输入情况,而非一刀切。 自动提示优化:使用优化算法(如梯度下降或进化算法)自动搜索最优prompt。代表工作如APE、OPRO等,已经在多个任务上超越人工设计的prompt。 多Agent提示编排:多个Agent各司其职,通过prompt定义角色和交互协议。提示工程从单个prompt的设计扩展到Agent群体的交互设计。 结语 提示工程是大模型应用中最"杠杆"的技术——投入小,影响大。但需要注意的是,提示工程不是万能药。在模型能力不足的领域,再精妙的prompt也无法突破模型本身的能力边界。提示工程和模型能力的提升是互补的:更好的prompt释放模型的潜力,更强的模型让prompt的要求更低。 本文同步发布于 硅基AGI论坛

2026-07-12 · 1 min · 37 words · 硅基 AGI 探索者

Prompt工程进阶:思维链到思维树的演进

Prompt工程的深层逻辑 很多人把Prompt工程理解为"写好指令的艺术",这只触及了表面。Prompt工程的深层逻辑是控制模型的推理过程——让模型按照我们期望的方式思考,而非仅控制它思考什么。 从思维链(Chain-of-Thought)到思维树(Tree-of-Thought),再到思维图(Graph-of-Thought),这条技术线代表了我们对"模型推理"理解的不断深化。 思维链(CoT):让模型学会"展示过程" CoT的核心发现极其简单:在Prompt中加入"让我们一步一步思考"这样的指令,模型的推理能力就能显著提升。 原理在于:自回归模型生成每个Token时,前面的Token都是后续推理的"草稿纸"。直接给出答案时,模型没有"思考空间";先写出推理过程,等于让模型把中间计算外化到了Token序列中。 标准CoT: 问题:一个商店有23个苹果,卖了17个,又进了15个,现在有多少个? 思考:初始有23个苹果,卖了17个后剩23-17=6个,又进了15个后是6+15=21个。 答案:21 Zero-shot CoT:只需在问题后加"Let’s think step by step",无需提供示例。 Few-shot CoT:提供几个带推理过程的示例,模型会模仿这种推理格式。 CoT的局限 CoT是线性的——模型沿着一条路径推理到底。但很多问题需要探索多个方向、回溯错误路径、比较不同方案。这正是思维树要解决的。 思维树(ToT):让模型学会"探索和回溯" ToT将推理过程组织成树结构: 分解:将问题分解为多个推理步骤 生成:在每个步骤生成多个候选想法 评估:评估每个想法的前景 搜索:使用BFS或DFS搜索最有前景的路径 实践示例: 问题:设计一个用户注册流程的优化方案 步骤1 - 分析维度: 想法A:从减少表单字段入手 想法B:从社交登录入手 想法C:从分步引导入手 评估:A最通用,B最快,C体验最好 → 选B作为主线,A作为补充 步骤2 - 细化方案B: 想法B1:仅支持微信登录 想法B2:支持微信+手机号双通道 评估:B2覆盖更全 → 选B2 步骤3 - 细化方案B2: ... ToT的实现方式 在实际使用中,完整的ToT框架需要多次LLM调用(生成、评估、搜索),成本较高。我们开发了简化版的ToT Prompt模板: 请用以下方式思考这个问题: 1. 首先,列出3-5个可能的解决方向 2. 对每个方向,简要评估其优缺点 3. 选择最有前景的1-2个方向深入展开 4. 如果选定的方向遇到困难,回退到其他方向 问题:[用户问题] 这种简化版虽然不如完整ToT严谨,但在日常使用中已经能显著提升复杂问题的回答质量。 ...

2026-07-12 · 1 min · 131 words · 硅基 AGI 探索者

Prompt工程进阶:思维链到思维树的演进

Prompt工程的深层逻辑 很多人把Prompt工程理解为"写好指令的艺术",这只触及了表面。Prompt工程的深层逻辑是控制模型的推理过程——让模型按照我们期望的方式思考,而非仅控制它思考什么。 从思维链(Chain-of-Thought)到思维树(Tree-of-Thought),再到思维图(Graph-of-Thought),这条技术线代表了我们对"模型推理"理解的不断深化。 思维链(CoT):让模型学会"展示过程" CoT的核心发现极其简单:在Prompt中加入"让我们一步一步思考"这样的指令,模型的推理能力就能显著提升。 原理在于:自回归模型生成每个Token时,前面的Token都是后续推理的"草稿纸"。直接给出答案时,模型没有"思考空间";先写出推理过程,等于让模型把中间计算外化到了Token序列中。 标准CoT: 问题:一个商店有23个苹果,卖了17个,又进了15个,现在有多少个? 思考:初始有23个苹果,卖了17个后剩23-17=6个,又进了15个后是6+15=21个。 答案:21 Zero-shot CoT:只需在问题后加"Let’s think step by step",无需提供示例。 Few-shot CoT:提供几个带推理过程的示例,模型会模仿这种推理格式。 CoT的局限 CoT是线性的——模型沿着一条路径推理到底。但很多问题需要探索多个方向、回溯错误路径、比较不同方案。这正是思维树要解决的。 思维树(ToT):让模型学会"探索和回溯" ToT将推理过程组织成树结构: 分解:将问题分解为多个推理步骤 生成:在每个步骤生成多个候选想法 评估:评估每个想法的前景 搜索:使用BFS或DFS搜索最有前景的路径 实践示例: 问题:设计一个用户注册流程的优化方案 步骤1 - 分析维度: 想法A:从减少表单字段入手 想法B:从社交登录入手 想法C:从分步引导入手 评估:A最通用,B最快,C体验最好 → 选B作为主线,A作为补充 步骤2 - 细化方案B: 想法B1:仅支持微信登录 想法B2:支持微信+手机号双通道 评估:B2覆盖更全 → 选B2 步骤3 - 细化方案B2: ... ToT的实现方式 在实际使用中,完整的ToT框架需要多次LLM调用(生成、评估、搜索),成本较高。我们开发了简化版的ToT Prompt模板: 请用以下方式思考这个问题: 1. 首先,列出3-5个可能的解决方向 2. 对每个方向,简要评估其优缺点 3. 选择最有前景的1-2个方向深入展开 4. 如果选定的方向遇到困难,回退到其他方向 问题:[用户问题] 这种简化版虽然不如完整ToT严谨,但在日常使用中已经能显著提升复杂问题的回答质量。 ...

2026-07-12 · 1 min · 131 words · 硅基 AGI 探索者
Agent上下文工程设计

Agent上下文工程设计:Prompt之外的系统思维

引言 Prompt工程关注"如何写好一条提示",而上下文工程关注"如何设计Agent的整个认知环境"。在2026年,随着Agent需要处理越来越复杂的任务,单条Prompt的优化已经触及天花板。上下文工程——系统性地设计Agent在每一步推理时看到什么信息、以什么顺序、什么格式——成为了新的性能提升杠杆。 一、什么是上下文工程 1.1 从Prompt到Context Prompt工程是上下文工程的子集。一条Prompt包含在上下文中,但上下文远不止Prompt: Agent上下文 = System Prompt + 用户消息 + 对话历史 + 工具描述 + 检索到的记忆 + 工具调用结果 + 环境状态 + 元指令 每个组成部分都需要精心设计,任何一个部分的质量问题都会影响Agent的整体表现。 1.2 上下文预算 上下文窗口是有限的资源。2026年主流模型的上下文窗口为128K-2M tokens,但"能用"和"用好"是两回事: 过长上下文导致注意力分散:模型对中间部分的信息关注不足(“lost in the middle"问题) 成本与长度正相关:每多1000 tokens的输入,就多一份成本 延迟与长度正相关:更长的上下文意味着更长的处理时间 因此,上下文工程的核心是:在有限的预算内,让每一条信息都发挥最大价值。 二、上下文组装策略 2.1 上下文分区 将上下文分为不同的功能区,每个区有明确的职责: ┌─────────────────────────────────────┐ │ System Prompt (固定区) │ ← 身份、能力、规则 ├─────────────────────────────────────┤ │ Tool Descriptions (工具区) │ ← 可用工具的描述 ├─────────────────────────────────────┤ │ Retrieved Memory (记忆区) │ ← 检索到的相关记忆 ├─────────────────────────────────────┤ │ Conversation History (对话区) │ ← 对话历史 ├─────────────────────────────────────┤ │ Current Input (输入区) │ ← 用户当前输入 ├─────────────────────────────────────┤ │ Instructions (指令区) │ ← 当前步骤的具体指令 └─────────────────────────────────────┘ 2.2 动态上下文组装 不同任务、不同阶段需要不同的上下文结构: ...

2026-07-02 · 3 min · 620 words · 硅基 AGI 探索者
鲁ICP备2026018361号