很多人把 AI 智能体的效果不好归因于“模型不够聪明”但从实际项目来看真正卡住系统上限的往往不是模型参数而是上下文获取策略——也就是你向模型“喂什么、怎么喂”。这个结论不是我拍脑袋。做过 Agent 工程的读者应该都有体会同一个模型输入一段含糊的“帮我分析一下这份日志”和输入一段带目标约束、格式约束、边界约束的完整提问输出质量差距巨大。更麻烦的是在智能体链路里提问不只是用户发来的那句话还包括系统提示词、工具返回结果、历史对话、外部检索材料。这些信息共同构成了模型的上下文而上下文的质量直接决定了 Agent 的决策质量。所以“最优提问”这件事本质上是一个可以建模、可以量化、可以优化的工程问题。它不再只是“提示词写得好不好”的玄学而是可以定义成目标函数在有限的上下文窗口预算下如何组织提问和材料使模型回答的正确率最高。这篇文章会沿着这个思路展开先拆解为什么提问会成为智能体瓶颈再给出目标函数框架接着落地到六个可操作的维度最后用完整的 Python 示例演示一个最小可运行的“目标函数式提问引擎”。无论你是在做基于 LangGraph 的本地 Agent还是在接企业级安全合规检测系统这套方法都能直接复用。1. 为什么提问质量会成为 AI 智能体的瓶颈先回到一个基础问题单轮对话式 AI 和智能体 Agent 对“提问”的要求根本不在一个量级。单轮对话场景下用户问一句模型答一句。上下文就是当前对话里的那几段文字模型的任务是理解并生成回复。此时提问质量当然重要但影响面有限——答得不好用户换个说法再问一次就行。智能体场景则完全不同。Agent 需要自主理解目标、规划步骤、调用工具、观察结果、修正行动最后给出结果。在这个过程中上下文获取发生在多个环节系统提示词里定义的 Agent 角色和目标。用户输入的任务描述。工具调用返回的数据比如数据库查询结果、API 响应、日志文件片段。多轮交互中的历史记忆。外部检索到的参考文档。任何一个环节的上下文质量出问题后续环节都会跟着出错。更麻烦的是智能体通常没有“再问一次”的容错空间——用户期望它自主完成任务而不是每步都回头确认。举几个贴近热词的真实场景。场景一企业级 AI 智能体安全合规自动化检测系统。这个 Agent 需要从多个安全系统中采集日志、检查配置、比对合规项。如果第一步提问就没有明确“检测范围是什么、重点检查哪些合规项、输出什么格式”Agent 可能抓了一堆无关日志最后漏掉关键漏洞。场景二基于 LangGraph、Ollama 构建本地 AI 智能体。本地模型通常上下文窗口比云端模型小而且推理成本更敏感。如果提问时把大量无关材料塞进上下文真正的关键信息可能被截断模型只能靠“猜”完成推理。场景三AI 智能体操控网站。Agent 需要通过 JS 插件采集页面 DOM 信息然后决定点击哪个按钮、填写哪个表单。如果操控指令描述模糊比如只说“把表单填好”而不说明字段映射关系、值从哪里来、校验规则是什么Agent 很容易点错元素或填入非法值。这三个场景的共同点是什么问题都不在模型推理能力而在上下文获取策略。换句话说模型拿到的材料是“脏的”、指令是“糊的”再强的推理能力也发挥不出来。所以做 Agent 工程的人真正应该投入精力的地方不是反复换更大参数的模型而是设计一套高质量的“提问系统”。这个系统回答的是三个问题该拿什么上下文给模型用什么结构组织这些上下文怎么判断这次提问的效果好不好2. 用目标函数重新定义最优提问“最优提问”听起来像是一个主观概念——什么算好问题不同人可能有不同答案。但如果我们把提问放到工程链路中就会发现它完全可以被量化。传统提问方式是这样思考的我想让模型做什么我把需求描述清楚然后让模型自由发挥。至于回答质量靠人工判断。目标函数式提问方式则换了一个思路先定义“什么是一次好回答”再反推“需要给模型什么上下文”。这个过程和机器学习里的目标函数优化非常相似。我们可以把最优提问形式化地写成max f(x) w1 * 信息增益 w2 * 可引导性 w3 * 可验证性其中信息增益模型从上下文中学到的新信息量用于减少任务的不确定性。可引导性提问中的指令是否足以让模型知道“该做什么、不该做什么、按什么顺序做”。可验证性模型的输出是否可以被客观检查比如字段是否完整、引用是否有依据。同时满足约束条件C1: 上下文 token 总量 预算 B C2: 检索/工具返回内容与任务相关性过滤 C3: 指令无歧义避免相互冲突的目标这个形式化表达的意义不在于“看起来专业”而在于它真正改变了提问的设计方法。过去我们设计提问时第一反应是“把话说清楚”。比如“请分析这份服务器日志找出所有错误信息并给出可能的原因。”这句话已经比“帮我看看日志”好很多但它没有定义“什么样的输出算合格”。模型可能只列了错误行没有给出原因可能原因写得太泛没有结合具体日志上下文可能一次性输出所有行造成信息过载。如果使用目标函数思维我们会先问自己这个提问的成功标准是什么然后倒推要得到结构化的分析结果提问里就必须指定输出格式。要避免模型泛泛而谈提问里就必须要求引用原始日志中的具体行号或时间戳。要控制输出长度提问里就必须给出摘要或结论优先的约束。要明确边界提问里就必须告诉模型“忽略”什么内容。这样设计出来的提问不是“更有文采”的问题而是“满足约束条件下能最大化回答质量”的问题。这里需要澄清一个常见误区目标函数不等于要求模型“必须输出 JSON”。虽然结构化输出经常是约束的一部分但目标函数关注的是更上层的策略——上下文如何被获取、裁剪、组织、优先级排序。输出格式只是其中一环。在实际项目中一个完整的目标函数式提问通常会拆解成下面几个组成部分。3. 上下文获取的六个维度我把实践中验证有效的上下文获取框架拆成六个维度每个维度对应提问中的一个必备组件。你可以把它理解成“提问清单”设计任何 Agent 提问时都可以逐项对照看自己遗漏了哪个部分。3.1 目标约束目标约束回答的是“这个提问要产生什么结果”。它必须足够具体不能只是一个动词。模糊目标分析这份日志找出异常。目标约束分析这份 Web 服务器访问日志识别 2025-01-06 14:00 至 15:00 时段内的 5xx 错误按出现次数排序输出 Top 5 的错误码与对应 URL。前者没有给出时间范围、错误类型、排序方式和输出数量模型只能靠猜测发挥。后者把结果形式限定死了模型的发挥空间被约束在正确方向内。3.2 格式约束格式约束定义了输出的结构和表达方式。它可以是 JSON、Markdown 表格、代码、简短摘要也可以是“结论先行 理由 建议”的段落结构。这里要特别注意格式约束不是越严格越好。如果任务是开放式的头脑风暴强行要求 JSON 会扼杀模型的发散能力。格式约束应该服务于任务类型。3.3 示例约束示例约束是六维中最容易产生误导的一维。一个精心挑选的示例比一大段文字说明更能让模型理解期望输出但一个错误的示例也会让模型“跑偏”得非常彻底。举个例子期望输出示例 [ {host: 10.0.1.5, error_type: ConnectionRefused, count: 32, sample_time: 14:32:07} ]这个示例同时告诉模型需要按 host 聚合、error_type 要使用统一术语、count 是次数、需要附带样例时间。它比写三行字段说明文档更直接。但如果你只给了一个示例模型可能会机械地按示例的结构输出忽略了其他应该覆盖的情况。所以示例约束的实践要点是选一个代表“大多数情况”的典型示例必要时再配一个反例说明什么情况不该出现。3.4 边界约束边界约束是对模型行为的“刹车系统”。它明确告诉模型什么不用做、什么不能做、什么情况不需要考虑。常见的边界约束包括忽略无关信息忽略 DEBUG 级别日志仅关注 WARN 及以上级别。禁止超出范围的操作本次只做只读分析不修改任何配置。条件触发边界只有检测到登录失败次数超过 10 次时才输出告警否则输出“未发现异常”。没有边界约束的 Agent 很容易“过度发挥”——用户只想要一个分析结论它却开始列出整改建议和后期规划。这在单轮对话里只是烦人在多步 Agent 链路里可能触发错误的工具调用。3.5 回退约束回退约束处理的是“信息不足时模型该怎么办”的问题。常见做法有两种明确声明不确定性如果信息不足以得出确定结论请直接说明“当前上下文不足以判断”不要猜测。触发信息补充动作在 Agent 链路中可以指示模型返回“需要更多信息”的状态码由调度器决定是否追加检索或询问用户。在实际项目中我见过很多 Agent 事故都源于模型在信息不足时强行下结论。回退约束不是“可选项”而是生产级 Agent 的必需品。3.6 验证约束验证约束是目标函数框架中最有“工程味道”的维度。它要求模型在输出答案时同时提供可验证的依据。例如如果结论涉及具体错误码请附上对应时间戳和日志原文片段。如果任务基于检索文档请标注结论对应的文档章节编号。如果进行了工具调用请附加工具返回值里与结论相关的字段。验证约束让评估结果从“主观判断”变成了“可检查的客观指标”。有了它才能闭环优化提问策略——这一点在第 4 节会详细展开。4. 把目标函数落地为工程闭环有了目标函数概念和六个维度下一步就是工程化落地。一个可运行的最优提问系统至少要包含四个模块。4.1 分层提问策略不要试图用一个超长 Prompt 解决所有问题。更稳妥的做法是分成三层系统层定义 Agent 角色、全局边界、通用输出风格。任务层定义本次任务的输入、输出格式、验证标准。数据层注入当前任务相关的具体事实材料。分层的好处是便于维护和复用。系统层不需要每次变化任务层按业务拆模板数据层动态组装。热词里提到的“人工智能 skills 怎么安装到 ai 智能体上”本质上也是在处理分层问题——Skill 定义了一种可复用的任务层能力安装后相当于把一套上下文获取策略固化成了插件。4.2 上下文包组装上下文不是“越多越好”。Material 必须经过筛选、裁剪、排序才能成为有效上下文。一个建议的组装顺序是任务指令回答要做什么核心事实数据日志、文档、工具结果中与任务直接相关的部分参考示例期望输出样例边界与回退说明什么不该做、信息不足怎么办4.3 输出评估评估是目标函数闭环的核心环节。没有评估就没有优化。在实际工程中可以采用“规则评分 人工抽样”的组合方式字段完整性输出是否包含要求的字段。引用覆盖率结论是否引用了给定的上下文材料。格式准确性输出是否符合指定的结构。规范性是否输出了边界外内容比如模型擅自“脑补”的外部知识。一致性结论是否与上下文中的事实相符。这些指标不是抽象的是可以逐项打分的。有了分数就可以对比不同提问策略的优劣。4.4 自动优化循环最后是把四个模块串成一个流程设计提问 → 组装上下文 → 执行推理 → 评估得分 → 根据得分调整提问策略 → 重新执行。这个循环一开始可以手动跑做好记录等数据积累到一定量级后再尝试用规则或小模型自动调整部分模板参数。这个过程很像调参你调的不是模型权重而是上下文获取策略。5. 完整示例一个最小可运行的“目标函数式提问引擎”下面用 Python 演示一个最小系统。场景固定为“日志分析 Agent”输入一段日志文本和用户目标系统自动生成目标函数式提问并提供一个评估函数给回答打分。5.1 提问策略数据结构先定义一个提问策略的数据结构对应前面说的六个维度。# 文件路径question_strategy.py from dataclasses import dataclass, field from typing import Optional dataclass class QuestionStrategy: 目标函数式提问策略 goal: str # 目标约束 output_format: str text # 格式约束text / json / markdown example: Optional[str] None # 示例约束 boundaries: list field(default_factorylist) # 边界约束 fallback: str 如果信息不足请直接说明无法判断不要猜测。 # 回退约束 verification: str 如果结论涉及具体数据请引用原始日志中的行号和关键词。 # 验证约束 def build_prompt(self, context: str) - str: 把策略和上下文组装成最终的 Prompt parts [ f任务目标{self.goal}, f输出格式{self.output_format}, ] if self.example: parts.append(f期望输出示例\n{self.example}) if self.boundaries: boundary_text .join(self.boundaries) parts.append(f边界约束{boundary_text}) parts.append(f回退约束{self.fallback}) parts.append(f验证要求{self.verification}) parts.append(f上下文材料\n{context}) return \n\n.join(parts)这段代码的核心是把六维度参数化。实际项目中goal、boundaries 等字段可以存数据库或配置文件由调度器动态填充。5.2 上下文组装函数下面的函数演示如何从原始日志中做基础裁剪只保留与目标相关的部分。这里用最简单的行过滤做演示线上系统通常会用更复杂的检索策略。# 文件路径context_builder.py from typing import List def build_context( raw_logs: str, keywords: List[str], max_lines: int 50 ) - str: 从原始日志中筛选与任务相关的行控制上下文预算。 selected_lines [] for line in raw_logs.strip().splitlines(): if any(kw.lower() in line.lower() for kw in keywords): selected_lines.append(line) if len(selected_lines) max_lines: break if not selected_lines: return 未检索到包含指定关键词的日志行 return \n.join(selected_lines)这个函数解决的是 C1 约束把上下文 token 总量控制在一定范围内。同时它也是 C2 相关性过滤的简版实现。5.3 输出评估函数评估函数定义了“一次回答好不好”的可量化标准。示例里采用简单的规则打分总分 10 分。# 文件路径evaluator.py import re def evaluate_answer( answer: str, question_strategy, context_keywords: List[str] ) - dict: 对模型回答进行规则打分返回分项和总分。 评分规则 1. 格式要求JSON 任务检查是否可解析text 任务检查长度。 2. 引用要求答案中是否包含日志中的关键词。 3. 回退要求信息不足时是否明确声明而不是伪造事实。 score 0 details {} # 1. 格式准确性 if question_strategy.output_format json: if re.search(r\[.*\]|\{.*\}, answer, re.S): score 3 details[format] 3 else: details[format] 0 else: if len(answer) 50: score 3 details[format] 3 else: score 1 details[format] 1 # 2. 引用覆盖率 hit_keywords [kw for kw in context_keywords if kw.lower() in answer.lower()] if hit_keywords: score 4 details[citation] 4 else: details[citation] 0 # 3. 回退约束 has_unknown_flag (无法判断 in answer) or (信息不足 in answer) if has_unknown_flag: score 1 details[fallback] 1 else: # 没有声明未知但也没有编造信息给部分分 score 0 details[fallback] 0 # 4. 边界约束出现明显越界词汇要扣分 forbidden_markers [我可以访问外部网络, 已自动修复, 已修改配置] for marker in forbidden_markers: if marker in answer: score - 2 details[boundary_penalty] -2 break total_score max(0, min(10, score)) return { total: total_score, details: details, cited_keywords: hit_keywords, }这个评估函数很简单但能说明目标函数的核心思路好坏判断是可记录的、可比较的。5.4 主流程串联最后把三个模块串起来模拟一次完整的“目标函数式提问”执行。# 文件路径main.py from question_strategy import QuestionStrategy from context_builder import build_context from evaluator import evaluate_answer # 原始日志模拟 raw_logs 14:00:11 INFO 10.0.1.5 GET /api/user 200 14:05:23 WARN 10.0.1.6 GET /api/order 500 14:12:47 ERROR 10.0.1.5 POST /api/pay 500 14:15:02 ERROR 10.0.1.6 GET /api/cart 500 14:20:33 INFO 10.0.1.5 GET /api/user 200 14:25:56 ERROR 10.0.1.7 GET /api/order 503 # 1. 构建上下文只保留 ERROR 和 WARN 行 keywords [ERROR, WARN, 500, 503] context build_context(raw_logs, keywords, max_lines20) print( 上下文材料 ) print(context) print() # 2. 定义目标函数式提问策略 strategy QuestionStrategy( goal分析日志中的 5xx 错误按 IP 聚合错误次数并输出 Top 2, output_formatjson, example[ {ip: 10.0.1.6, error_count: 2, error_codes: [500, 500]} ], boundaries[ 仅关注 5xx 错误忽略 2xx 和 4xx, 不要输出修复建议, 不要修改任何配置, ], ) prompt strategy.build_prompt(context) print( 完整 Prompt ) print(prompt) print() # 3. 模拟模型回答实际项目中使用 LLM 接口 mock_answer [ {ip: 10.0.1.6, error_count: 2, error_codes: [500, 500]}, {ip: 10.0.1.5, error_count: 2, error_codes: [500]} ] # 4. 评估回答质量 result evaluate_answer(mock_answer, strategy, keywords) print( 评估结果 ) print(f总分{result[total]} / 10) print(f分项明细{result[details]}) print(f命中关键词{result[cited_keywords]})6. 运行结果与效果验证运行上面的 main.py预期会看到三段输出上下文材料、完整 Prompt、评估结果。模拟回答中IP 10.0.1.6 出现了两次 500聚合为 2 次正确IP 10.0.1.5 出现了两次 500聚合为 2 次但代码里 error_codes 只列了一个 500这在严格字段校验时会被判为不完整。所以评估函数会给出一个中间档的分数而不是满分。这个设计是故意的评估函数能不能发现“字段缺失”这种细节直接决定了目标函数优化是否有效。如果评估只看有没有关键词模型就会学会“表面引用实质偷工减料”。下面用三种提问方式做对照更容易看出差异。假设同一个日志分析任务提问方式提示内容示例典型输出问题预估评估得分模糊提问帮我看看日志输出泛泛无明确结论2-3 分详细自然语言提问请分析这份日志中的错误并给出可能原因要求详细一些格式不统一有脑补修复建议5-6 分目标函数式提问包含目标、格式、示例、边界、回退、验证约束的 Prompt结构规范能按 IP 聚合字段完整8-10 分如果运行后发现评估得分非常低优先按以下顺序排查检查 build_context 是否真的筛选到了相关日志行。关键词拼写错误是常见问题。检查 Prompt 中格式约束与实际数据是否匹配。比如要求 JSON 数组但示例里写了对象。检查评估函数的关键词列表是否和上下文关键词一致。评估逻辑与上下文脱节时分数没有参考价值。检查边界约束是否被自动改写或覆盖。多步 Agent 链路中后置指令可能无意中覆盖前置约束。7. 常见问题与排查思路这一节整理我在实践和读者反馈中常见的问题按“问题现象 - 可能原因 - 排查方式 - 解决方案”组织。问题现象可能原因排查方式解决方案材料给的越多回答越差上下文未做相关性过滤噪声覆盖关键信息查看实际进入 Prompt 的上下文裁剪结果增加关键词过滤、时间窗口裁剪、RAG 排序提问模板太长模型截断系统层任务层数据层一次性拼入token 超预算统计 token 消耗定位超限部分分层管理压缩系统层描述优先保留核心事实数据给了示例反而回答跑偏示例太特殊模型机械模仿结构忽略了其他情况对比有无示例时的输出差异增加反例说明或在示例旁标注“这只是其中一种情况”工具返回结果没有参与后续推理Agent 链路中工具结果未追加到上下文模型“看不到”检查多轮对话消息历史中是否包含工具返回内容把工具返回封装为 ToolResult 消息追加到下一次模型调用前评估得分与人工判断不一致评估规则太粗只覆盖格式和关键词没有覆盖语义抽样对比规则评分与人工评分的差距增加语义相似度评估或引入小模型打分辅助本地模型如 Ollama推理结果不稳定上下文窗口小长 Prompt 被截断或量化导致推理能力波动打印输入 Prompt 的 token 数观察截断边界精简上下文保留核心行减小输出 max_tokens必要时换更大窗口模型Agent 反复执行无关操作目标约束缺失或太宽泛模型没有明确“结束条件”检查任务层目标描述和边界约束显式写明完成标志和终止条件比如“当所有 IP 统计完成后立即输出结果”8. 最佳实践与工程建议最后一部分聊一些从实践中沉淀下来的工程建议。这些建议不针对某个具体框架适用于大多数 Agent 项目。8.1 提问模板要有版本管理提问模板本质上是代码应该用代码的方式管理。每次修改目标函数参数、六维度文案都要能回溯。否则你很难判断“这周 Agent 效果波动”到底是因为模型更新还是因为某个同事悄悄改了 Prompt。8.2 上下文预算要主动分配上下文窗口是硬约束。我的经验是把预算按比例拆分再逐个模块控制事实材料60% 左右这是模型决策的主要依据。指令与约束20% 左右包括目标、边界、回退、验证要求。示例10% 左右一个典型示例加一个反例。输出提示与其他10% 左右。这个比例不是绝对的但它提供了一个检查起点如果事实材料占比过低说明指令写得太啰嗦如果示例占比过高说明示例数量过多需要精简。8.3 区分本地模型和云端模型本地模型和云端模型的差异不只是“贵和便宜”的区别还体现在提问策略上。本地模型例如通过 Ollama 部署上下文窗口更小指令理解能力略弱所以提问要更精炼事实材料要去噪尽量避免长段嵌套指令。云端模型上下文窗口大推理能力强但成本更高、延迟更高所以要在“尽可能多给材料”和“控制成本”之间找平衡。换句话说目标函数的参数需要针对不同模型重新标定。你不可能用同一套 Prompt 模板通吃所有模型。8.4 安全合规类 Agent 的特殊要求如果你在做企业级 AI 智能体安全合规自动化检测系统目标函数框架里有几点需要额外强调必须保留审计日志每次提问的内容、上下文来源、模型输出、评估得分都要记录便于事后追溯。禁止跳过校验步骤边界约束里要明确写“任何情况下不得跳过检测项”并在评估函数中加“越权跳过”扣分项。工具操作遵循最小权限Agent 调用敏感工具时默认只读修改类操作单独开权限并在 Prompt 中写死。这些不是技术能力问题而是安全治理问题。目标函数中需要把合规性作为最大权重的一项约束。8.5 评估一定要闭环很多人做 Agent 项目会花大量时间调 Prompt但从来不建立评估机制。结果是今天效果好明天效果差却说不清差在哪。建议从一开始就建立“提问-评估”的循环。最简单的方式是每次任务执行后把 Prompt 和回答连同评估得分一起写入日志。积累一周后按得分排序找出表现最差的几类任务针对性优化模板。这才是把“最优提问”从一个观点变成工程能力的关键。9. 总结与后续学习方向这篇文章的核心观点是一句话最优提问的实质是把上下文获取当作一个系统工程来设计目标函数不是数学公式而是一种思维工具——先定义“回答得对”的标准再倒推“该怎么提问、该喂什么材料”。从这个视角看很多困扰 Agent 开发的问题都有了新的解法模型效果不好先别急着换模型检查一下上下文获取策略。Prompt 写不好先别急着学“提示词技巧”先把六维度清单过一遍。Agent 乱跑乱操作先别急着加规则先看看目标约束和边界约束是否清晰。评估说不清好坏先别急着靠感觉建立规则评分体系。下一步实践建议从你手头的一个 Agent 任务开始按文中的 QuestionStrategy 数据结构改造现有 Prompt跑三天每天记录评估得分。你会发现即使不换模型效果也会有明显变化。值得继续深入的方向还有三个一是自动评估用小模型或者规则引擎替代人工评分扩大评估覆盖范围二是上下文压缩把长文档压缩成摘要或结构化要点后再注入 Prompt三是多轮记忆管理优化历史对话的取舍策略避免记忆污染。如果你正在做智能体开发或者在 LangGraph、Ollama 这类工具链上搭建本地 Agent建议把这套“目标函数式提问”思路收藏备用。下次再遇到“模型不够聪明”的问题先回头看看自己的提问和上下文也许问题的答案就在这里。