AI智能体输入编译器：从自然语言到结构化任务流的工程实践-开发者社区

1. 项目概述：一个为AI智能体“翻译”人类指令的编译器

最近在折腾AI智能体（Agent）的开发，发现一个挺有意思的痛点：我们人类随口说的一句话，比如“帮我查一下明天北京的天气，然后告诉我该穿什么衣服”，对于智能体来说，其实是一团需要被解析、拆解和执行的复杂指令。这中间存在一个巨大的“语义鸿沟”。我一直在寻找一个工具，能优雅地把我们日常的、模糊的、多模态的输入，编译成智能体内部执行引擎能够精准理解和处理的结构化任务流。直到我遇到了Jatbas/agent-input-compiler这个项目，它精准地戳中了这个需求。

简单来说，agent-input-compiler是一个专门为AI智能体设计的“输入编译器”。它的核心工作不是生成内容，而是“翻译”和“规划”。它接收用户用自然语言、图片、文件甚至语音发出的原始指令，然后通过一系列解析、推理和结构化处理，输出一个清晰的、可执行的“任务清单”或“工作流蓝图”。这个蓝图会明确告诉智能体：你要先调用哪个工具（Tool），传入什么参数，然后根据上一步的结果，再执行下一步什么操作。它让智能体从“听到指令后一脸茫然”，变成了“拿到一份清晰的SOP（标准作业程序）”。

这个项目非常适合两类朋友：一是正在构建复杂AI智能体应用（比如自动化客服、个人助理、工作流自动化机器人）的开发者，它能极大降低智能体任务规划模块的开发难度；二是对AI智能体底层交互逻辑感兴趣的研究者或学习者，通过这个项目，你能非常直观地理解从“用户意图”到“机器动作”的完整编译链条。接下来，我就结合自己的实践，带你深入拆解这个编译器的设计思路、核心模块以及如何把它集成到你自己的项目中。

2. 核心设计思路：从模糊意图到精确行动计划的翻译官

2.1 问题根源：智能体为什么需要“编译”？

要理解agent-input-compiler的价值，得先看看没有它的时候，智能体是怎么工作的。传统做法往往依赖于大型语言模型（LLM）的“零样本”或“少样本”提示（Prompting）。我们把用户指令和一堆工具描述塞给LLM，期望它直接输出一个JSON格式的调用指令。这种方法在简单场景下可行，但一旦任务变复杂，问题就来了：

指令模糊性：“分析一下这份财报”中的“分析”，具体指计算利润率、现金流分析还是风险提示？智能体需要自己猜。
多步骤依赖：“查天气然后推荐穿搭”包含两个有顺序依赖关系的子任务。LLM可能一次性生成所有步骤，但缺乏对步骤间数据流（如把天气结果传给穿搭推荐）的显式管理。
多模态输入处理：用户可能上传一张图片说“帮我把这里的文字摘出来并翻译”。这需要先识别图片中的文本（调用OCR工具），再将识别结果进行翻译（调用翻译工具）。LLM需要自己“想”出这个流程。
工具选择歧义：完成“订一张机票”这个任务，可能涉及查询航班、比价、下单支付等多个工具。LLM可能选错工具或遗漏步骤。

agent-input-compiler的设计思路，就是将这些原本压在LLM身上的“规划”负担，剥离出来，由一个专门的、可预测性更强的模块来承担。它的角色就像一个经验丰富的项目经理，接到一个模糊的需求后，不是立刻动手，而是先做需求分析、任务拆解（Work Breakdown Structure）、资源（工具）分配，最后产出一份可执行的项目计划表。

2.2 核心架构：三层编译流水线

这个编译器的运作，可以类比为一个三层过滤和转换的流水线：

输入感知与标准化层：这是前端。它负责接收各种格式的原始输入——文本、图像、音频、文档（PDF, Word）。对于非文本输入，它会调用相应的预处理模型（如Whisper用于语音转文本，OCR模型用于图像提取文字，文档解析器提取纯文本和元数据），将所有输入统一转化为富含语义的“增强文本”描述。例如，一张包含图表的图片，会被描述为“一张展示了2023年Q1-Q4季度销售趋势的折线图，横轴为季度，纵轴为销售额（单位：万元）”。
意图解析与任务分解层：这是核心的大脑。接收上一步的标准化文本描述，结合预定义的“工具包”（一个所有可用工具及其功能、参数、返回值的清单）进行深度分析。这一层通常由一个经过微调或精心设计提示词的LLM驱动。它的目标是：
- 识别核心意图：用户到底想达成什么目标？
- 拆解原子任务：将宏大意图分解为一个个不可再分、可直接调用工具完成的原子操作。比如“帮我做一份竞品分析报告”会被拆解为“搜索竞品A的最新信息”、“搜索竞品B的产品特性”、“提取两者的价格数据”、“对比核心功能列表”、“生成Markdown格式的对比报告”。
- 建立任务图谱：明确原子任务之间的依赖关系。哪些可以并行？哪些必须串行（B任务需要A任务的结果作为输入）？这形成了一个有向无环图（DAG）。
结构化输出与优化层：这是后端。将任务图谱编译成智能体执行引擎能直接消费的格式。agent-input-compiler通常输出一种结构化的数据格式，比如JSON或YAML。这个输出不仅包含任务列表，还包含每个任务对应的工具ID、输入参数模板（其中可能包含对上游任务输出结果的引用，如{{step1.output}}）、预期输出、以及错误处理策略（如某个工具调用失败，是重试、跳过还是整个流程终止）。

注意：这个三层架构是逻辑上的划分，在实际代码中可能耦合得比较紧密。但理解这个分层，对于后续调试和扩展至关重要。当你发现智能体对图片指令理解有偏差时，问题可能出在第一层；如果任务拆解得乱七八糟，问题就在第二层。

2.3 与常见方案的对比优势

你可能听说过LangChain的Agent、AutoGPT或微软的TaskWeaver。agent-input-compiler与它们定位有何不同？

vs LangChain Agent：LangChain的Agent更像一个“实时决策者”。它根据当前状态和工具描述，通过LLM动态决定下一步做什么。这种方式灵活，但不可预测、可能陷入循环，且调试困难。agent-input-compiler则是“预先规划者”，在行动前就制定好完整计划，执行过程确定、可追溯、效率更高，尤其适合复杂、多步骤的已知任务类型。
vs AutoGPT：AutoGPT强调自主目标达成，会自我规划并执行，但同样存在不可控和成本高的问题。agent-input-compiler更轻量、更专注，它只做“规划”这一件事，将“执行”交给更专业的智能体框架，边界清晰，易于集成。
vs TaskWeaver：TaskWeaver是一个更重量级的、面向数据分析的智能体框架，其内置的“Planner”模块与agent-input-compiler理念相似。但agent-input-compiler作为一个独立、专注的项目，更易于被集成到各种不同的智能体架构中，定制化程度也更高。

核心优势总结：agent-input-compiler通过将“规划”阶段前置化和专业化，带来了确定性、可调试性和执行效率的显著提升。它输出的不是一段自然语言，而是一份机器友好、无歧义的工作流说明书。

3. 核心模块深度解析与实操配置

了解了设计思路，我们深入到代码和配置层面。假设我们已经克隆了Jatbas/agent-input-compiler项目，它的目录结构通常包含以下几个关键部分：

agent-input-compiler/ ├── core/ │ ├── compiler.py # 编译器主类，协调整个流程 │ ├── input_processor.py # 输入感知与标准化层实现 │ ├── planner.py # 意图解析与任务分解层实现（核心） │ └── output_formatter.py # 结构化输出层实现 ├── tools/ │ └── tool_registry.py # 工具注册与管理中心 ├── configs/ │ ├── planner_config.yaml # 任务规划器的配置（如使用的LLM、提示词模板） │ └── processing_config.yaml # 输入处理的配置（如OCR服务地址） ├── prompts/ # 存放给LLM的提示词模板 │ └── task_decomposition.j2 └── examples/ # 使用示例

3.1 工具注册表：定义智能体的“技能库”

这是整个编译器的基石。智能体能做什么，完全取决于你在tool_registry里注册了哪些工具。这里的注册不是简单的列表，而是要给每个工具一份清晰的“说明书”。

实操：如何定义一个工具？

在tools/tool_registry.py中，你会看到类似下面的数据结构：

class ToolRegistry: def __init__(self): self._tools = {} def register(self, tool: Dict): """注册一个工具。""" # 工具定义示例 tool_spec = { "id": "web_search", # 唯一标识符 "name": "网络搜索", "description": "使用搜索引擎在互联网上查询信息。适用于查找实时信息、事实核查、获取最新资讯。", "parameters": { "type": "object", "properties": { "query": { "type": "string", "description": "搜索关键词，应具体明确。例如：‘2024年人工智能大会最新议题’ 而非 ‘找点AI资料’。" }, "max_results": { "type": "integer", "description": "返回的最大结果数量，默认为5。", "default": 5 } }, "required": ["query"] # 必填参数 }, "returns": { "type": "array", "description": "搜索结果的列表，每条结果包含标题、摘要和链接。" } } self._tools[tool_spec["id"]] = tool_spec

关键点解析与避坑指南：

description字段至关重要：这是LLM（规划器）理解工具用途的唯一依据。描述要具体、场景化。对比一下：
- 差的描述：“搜索网络”。（太模糊，LLM不知道什么时候该用它）
- 好的描述：“使用搜索引擎在互联网上查询信息。适用于查找实时信息、事实核查、获取最新资讯。不适用于查询内部数据库或已提供的文档内容。”
参数描述要细致：parameters[‘properties’][‘query’][‘description’]是指导LLM如何生成输入参数的关键。给出好例子和坏例子，能极大提高规划准确性。
工具粒度要适中：工具应该是一个“原子操作”。不要注册一个“进行竞品分析”的巨无霸工具，而应该拆分成“搜索公司信息”、“提取网页正文”、“比较产品特性”等小工具。这样编译器才能灵活组合。
返回类型要声明：明确告诉规划器这个工具会返回什么格式的数据（字符串、列表、字典等），这有助于下游任务引用其输出。

实操心得：在项目初期，花时间精心打磨每个工具的“说明书”，比后期反复调整提示词要有效得多。可以组织一个小测试集，用各种自然语言指令去测试规划器是否能正确选择你期望的工具，根据测试结果反复优化工具描述。

3.2 规划器：任务拆解的大脑

规划器（planner.py）是编译器的CPU，它通常封装了一个LLM的调用。它的核心是一个精心设计的提示词模板（通常在prompts/目录下）。

核心提示词模板拆解：

一个典型的task_decomposition.j2提示词可能包含以下部分：

你是一个高级任务规划AI。你的目标是将用户的请求分解为一系列可执行的步骤。 可用的工具如下： {% for tool in tools %} - [{{tool.id}}] {{tool.name}}: {{tool.description}} 参数: {{tool.parameters}} {% endfor %} 用户请求：{{user_input}} 请遵循以下规则进行分析： 1. 理解用户的最终目标。 2. 将目标分解为连续的步骤。每个步骤必须对应一个且仅一个上述可用工具。 3. 明确步骤间的依赖关系。如果一个步骤需要另一个步骤的输出，请明确指出。 4. 为每个步骤指定工具ID和具体的输入参数值。参数值应基于用户请求和常识推断，如果无法确定，请使用合理的占位符或说明需要用户澄清。 5. 输出格式必须是严格的JSON，结构如下： { "goal": "用户的最终目标描述", "steps": [ { "id": "step_1", "tool_id": "web_search", "parameters": {"query": "具体的搜索词"}, "depends_on": [] // 依赖哪些步骤的id }, ... ] }

配置与调优要点：

在configs/planner_config.yaml中，你需要配置规划器：

planner: llm_provider: "openai" # 或 "anthropic", "azure_openai", "local"（使用Ollama等） model_name: "gpt-4-turbo-preview" # 对于复杂任务，GPT-4系列比GPT-3.5可靠得多 temperature: 0.1 # 设置为较低值，保证任务规划的确定性和一致性 max_tokens: 2000 # 提示词模板路径 prompt_template: "./prompts/task_decomposition.j2" # 重试与容错 max_retries: 2 retry_delay: 1

LLM选型：对于生产环境，强烈建议使用能力最强的模型（如GPT-4、Claude 3）。任务规划需要深度的逻辑推理和理解能力，小模型或弱模型在这里的失败率会很高，导致整个流程崩溃。
Temperature设置：务必设置为一个很低的值（如0.1或0.2）。我们需要的是稳定、可靠的任务分解，而不是创意性的发散。高temperature会导致相同的输入产生截然不同的计划，难以调试。
结构化输出：提示词中必须强制要求LLM输出指定格式的JSON。很多LLM支持“JSON mode”，在API调用时开启这个功能可以极大提高输出格式的合规性。

3.3 输入处理器：多模态信息的统一入口

input_processor.py负责将五花八门的输入变成规划器能理解的文本。它的实现取决于你希望支持哪些模态。

常见处理链配置示例：

# configs/processing_config.yaml input_processor: text: enabled: true # 文本预处理，如去除无关字符、截断等 max_length: 10000 image: enabled: true ocr_provider: "paddleocr" # 可选 tesseract, google_vision # 除了提取文字，还可以用视觉LLM（如GPT-4V）生成图片描述 enable_vision_llm: false vision_llm_model: "gpt-4-vision-preview" document: enabled: true supported_types: [".pdf", ".docx", ".txt"] pdf_extractor: "pymupdf" # 或 pdfplumber audio: enabled: false # 按需开启 stt_provider: "openai_whisper"

实现逻辑伪代码：

class InputProcessor: def process(self, input_data: Union[str, bytes, Path]) -> str: enhanced_description = "" if is_image(input_data): text_from_ocr = self._call_ocr_service(input_data) if self.config.enable_vision_llm: image_description = self._call_vision_llm(input_data) enhanced_description = f"图片内容描述：{image_description}。图片中识别出的文字：{text_from_ocr}" else: enhanced_description = f"图片中识别出的文字：{text_from_ocr}" elif is_pdf(input_data): text, metadata = self._extract_from_pdf(input_data) enhanced_description = f"文档内容：{text[:2000]}... [文档共{metadata['pages']}页]" else: # 默认为文本 enhanced_description = self._clean_text(input_data) return enhanced_description

注意事项：

成本与延迟：调用OCR、视觉LLM、语音转文本等服务都会产生额外成本和延迟。需要根据应用场景权衡。对于内部文档处理，可能只需要OCR；对于需要理解图表含义的场景，才需要启用视觉LLM。
信息过载：从PDF或长文中提取的文本可能非常长，直接塞给规划器会浪费token且可能干扰重点。需要设计摘要或关键信息提取策略，或者分块处理。

4. 集成与实战：将编译器接入你的智能体

假设我们已经有了一个基于LLM的智能体基础框架，它能够调用注册的工具。现在，我们需要把agent-input-compiler作为这个智能体的“前置规划模块”集成进去。

4.1 基础集成流程

整个工作流如下：

# 1. 初始化编译器 from core.compiler import AgentInputCompiler from tools.tool_registry import ToolRegistry tool_registry = ToolRegistry() # ... 注册所有工具 ... compiler = AgentInputCompiler(tool_registry, config_path="./configs") # 2. 接收用户原始输入 user_input = "帮我分析一下附件中的销售图表，总结趋势，并和去年同期的数据报告（report_q4_2022.pdf）做个对比，最后给我一个PPT大纲。" # 3. 编译输入，得到任务计划 try: # 假设用户输入包含文件路径或上传的文件对象 compiled_plan = compiler.compile(user_input, attached_files=["sales_chart.png", "report_q4_2022.pdf"]) except Exception as e: # 处理编译错误，如LLM调用失败、输入无法解析等 log.error(f"Compilation failed: {e}") # 可以降级处理，例如直接将原始输入交给智能体，或返回一个错误提示让用户澄清 fallback_response = "抱歉，我暂时无法处理这个复杂的请求。您可以尝试将问题拆分成更小的步骤。" return fallback_response # 4. 解析并执行计划 # compiled_plan 是一个字典，结构如之前提示词中定义的JSON goal = compiled_plan["goal"] steps = compiled_plan["steps"] # 5. 智能体执行引擎接管 agent_executor = YourAgentExecutor(tool_registry) execution_results = {} for step in steps: # 检查依赖是否满足 if all(dep in execution_results for dep in step["depends_on"]): # 准备参数：将参数模板中的变量（如{{step1.output}}）替换为实际结果 resolved_params = resolve_parameters(step["parameters"], execution_results) # 调用工具 result = agent_executor.execute_tool(step["tool_id"], resolved_params) execution_results[step["id"]] = result else: # 处理依赖未满足的错误（理论上规划器不应产生这种情况） log.warning(f"Dependency not met for {step['id']}") break # 6. 汇总执行结果，生成最终响应给用户 final_output = synthesize_results(goal, execution_results)

4.2 处理复杂依赖与循环

规划器生成的任务图谱可能包含并行步骤。一个简单的执行器是按顺序串行执行，但为了效率，我们需要一个能处理DAG的调度器。

简易DAG调度实现思路：

from collections import deque, defaultdict def execute_plan(plan: Dict, executor): steps = plan["steps"] # 构建邻接表和入度表 adj = defaultdict(list) in_degree = {s["id"]: 0 for s in steps} step_map = {s["id"]: s for s in steps} for step in steps: for dep in step.get("depends_on", []): adj[dep].append(step["id"]) in_degree[step["id"]] += 1 # 拓扑排序执行 queue = deque([sid for sid, deg in in_degree.items() if deg == 0]) results = {} while queue: current_id = queue.popleft() step = step_map[current_id] # 解析并执行当前步骤 params = resolve_parameters(step["parameters"], results) step_result = executor(step["tool_id"], params) results[current_id] = step_result # 更新依赖此步骤的后续步骤的入度 for next_id in adj[current_id]: in_degree[next_id] -= 1 if in_degree[next_id] == 0: queue.append(next_id) # 检查是否所有步骤都执行完毕（图中应无环） if len(results) != len(steps): raise Exception("Cycle detected in task graph or some steps cannot be executed.") return results

这个调度器确保了任务按照正确的依赖顺序执行，并且可以并发执行入度为0的独立任务（如果执行器支持异步的话）。

4.3 错误处理与鲁棒性设计

在实际运行中，编译和执行都可能出错。必须设计健壮的错误处理机制。

编译时错误：
- LLM调用失败：网络超时、API限额用完。实现重试机制和优雅降级（如使用更便宜的模型回退）。
- 输出格式错误：LLM没有返回有效JSON。可以在提示词中强化，并在代码中添加解析校验和自动修复尝试（例如，用正则提取JSON部分）。
- 工具选择无效：规划器选择了一个未注册的工具ID。编译阶段就应校验并报错。
运行时错误：
- 工具执行失败：网络错误、参数错误、第三方服务异常。每个步骤应有超时和重试配置。更重要的是，规划器可以支持定义“错误处理策略”。例如，在步骤定义中增加on_error: "skip" | "retry" | "abort"字段。
- 依赖数据缺失：上游步骤的输出不符合下游步骤的输入期望。这需要在工具定义和参数解析时做更严格的类型和结构校验。可以在规划阶段就让LLM思考得更周全，或者在执行时进行数据转换适配。

一个增强的步骤定义示例：

{ "id": "step_2", "tool_id": "data_visualizer", "parameters": {"data": "{{step_1.output}}", "chart_type": "line"}, "depends_on": ["step_1"], "error_policy": { "on_failure": "retry", "max_retries": 2, "fallback_action": "skip_and_log" // 如果重试失败，跳过此步骤并记录，不影响后续 } }

5. 高级特性与扩展方向

agent-input-compiler作为一个基础框架，留下了很多可以扩展和优化的空间。

5.1 上下文记忆与历史感知

当前的编译器是“无状态”的，每次编译都独立进行。但在对话式智能体中，用户指令往往有上下文。例如，用户先说“查一下杭州的天气”，然后说“那上海呢？”。第二个指令“那上海呢？”依赖于历史上下文。

扩展思路：在compile方法中增加conversation_history参数。在构建给规划器的提示词时，不仅传入当前用户输入，还传入最近几轮的历史对话和对应的执行结果摘要。这样规划器就能理解“那上海呢？”指的是“查询上海的天气”，并复用之前的工具和逻辑。

class ContextAwareCompiler(AgentInputCompiler): def compile(self, current_input, history=None, attached_files=None): enriched_input = self._build_contextual_prompt(current_input, history) return super().compile(enriched_input, attached_files)

5.2 动态工具发现与加载

在大型系统中，工具集可能非常庞大，或者动态变化。每次都将所有工具描述塞进提示词，会浪费token且可能超出上下文长度。

优化方案：实现一个“工具路由”或“工具检索”层。先用一个快速的LLM或一个嵌入模型，根据用户输入检索出最相关的N个工具，只把这些工具的描述传给规划器。这类似于RAG（检索增强生成）的思想。

# 伪代码：工具检索 def retrieve_relevant_tools(user_input: str, tool_registry: ToolRegistry, top_k: int = 10): # 为每个工具生成描述向量并存入向量数据库 # 将用户输入也转化为向量 # 进行相似度检索，返回top_k个最相关的工具 relevant_tools = vector_db.similarity_search(user_input, k=top_k) return relevant_tools

5.3 计划验证与用户确认

对于涉及敏感操作（如发送邮件、修改数据、支付）或资源消耗大的任务，自动生成的计划在执行前，最好能展示给用户确认。

可以设计一个“计划解释器”，将结构化的任务计划翻译成人类可读的自然语言摘要，例如：“我将为您执行以下操作：1. 使用网络搜索查找‘GPT-4最新技术论文’；2. 下载找到的前3篇PDF论文；3. 使用摘要工具分别概括每篇论文的核心内容；4. 将三个摘要整合成一份对比报告。确认开始执行吗？”

这增加了系统的透明度和安全性，也让用户有最终的控制权。

6. 常见问题与调试技巧实录

在实际集成和使用agent-input-compiler的过程中，我踩过不少坑，也总结了一些调试技巧。

6.1 问题：规划器总是选错工具或拆解不合理

排查步骤：
1. 检查工具描述：这是最常见的原因。回到3.1节，用“新手小白”的视角重读你的工具描述，是否足够清晰、无歧义？是否说明了适用和不适用的场景？
2. 隔离测试规划器：构造一个最简单的测试，只给规划器用户输入和工具列表，看它的输出。排除输入处理器和后续执行的影响。
3. 审查提示词：提示词中的规则是否足够明确？是否要求LLM“一步一步思考”？尝试在提示词中加入更具体的约束，比如“如果用户请求涉及计算，请优先使用calculator工具，而不是search工具”。
4. 调整LLM参数：确保temperature=0.1或更低。尝试换用更强的模型（如从GPT-3.5升级到GPT-4）。
5. 提供少量示例：在提示词中加入2-3个高质量的“用户输入 -> 任务计划”的示例（Few-shot Learning），能极大地引导LLM的输出格式和逻辑。

6.2 问题：编译过程太慢，影响用户体验

优化策略：
1. 缓存：对于常见的、重复的用户请求（例如“今天天气怎么样”），可以对编译结果进行缓存。以用户输入+工具注册表的哈希值为Key，缓存编译出的计划。
2. 异步编译：如果UI允许，可以在用户开始输入或上传文件时，就启动一个低优先级的编译预加载。
3. 简化输入处理：关闭非必要的多模态处理功能。例如，如果用户上传图片但指令是“把这张图存起来”，就不需要调用OCR和视觉LLM。
4. 使用更快的LLM：对于任务规划，一些专门针对推理优化的模型（如Claude Haiku）可能比大型通用模型更快，且成本更低，需要在效果和速度间权衡。

6.3 问题：任务计划看起来正确，但执行时失败

调试方法：
1. 日志记录：在编译和执行的关键节点打上详细的日志。记录下：原始输入、增强后的输入、规划器收到的完整提示词、规划器的原始输出、解析后的任务计划、每一步执行前的参数（替换变量后）、每一步执行的结果或错误。
2. 参数解析验证：重点检查resolve_parameters函数。打印出每一步执行前的resolved_params，看变量替换是否正确。常见问题是上游步骤的输出是一个复杂对象，而下游步骤的参数期望只是一个字符串字段，导致类型不匹配。
3. 工具兼容性：确保规划器选择的工具，其实际实现的函数签名（参数名称、类型）与注册时描述的完全一致。一个大小写错误都可能导致调用失败。

6.4 问题：如何处理用户指令中的模糊和歧义？

这是AI系统的固有问题，编译器无法完全解决，但可以缓解。

策略一：主动澄清：在规划器中设计一个“歧义检测”环节。如果LLM认为指令的关键参数缺失或模糊（例如，“帮我订机票”没有时间、目的地），可以让编译器中断流程，并生成一个澄清问题（“请问您要订去哪里的机票，什么时间出发？”）返回给用户，等待用户补充信息后再重新编译。
策略二：合理假设：在工具的参数描述中，引导LLM做出合理假设。例如，对于“查天气”，如果用户没说地点，参数描述可以写“如果用户未明确指定地点，默认查询用户IP所在地的天气”。
策略三：提供备选计划：让规划器生成1-3个最可能的任务计划，并附带置信度或简要理由，由上层逻辑或用户来选择。

集成agent-input-compiler后，我最深刻的体会是，它并没有让智能体变得更“智能”，而是让它变得更“可靠”和“可控”。它将智能体中最不可预测的部分——从自然语言到行动计划的转换——封装成了一个可调试、可优化、可预测的模块。这让我们能够像优化传统软件一样，通过改进提示词、调整工具描述、增加校验规则来系统地提升整个智能体的表现。它可能不是构建智能体的唯一路径，但对于追求稳定性和复杂任务处理能力的应用场景来说，这条“先规划，后执行”的路径，无疑提供了更坚实的工程基础。如果你也在为智能体的任务规划头疼，不妨从这个项目开始，亲手搭建一个属于你自己的“指令翻译官”。