Agent 的「观察空间「和「行动空间「应该如何设计

1️⃣ 考察意图

面试官想看你能否从"RL（强化学习）视角"设计 Agent 的信息输入和行为输出空间。刁钻点在于：很多人只答"观察空间是 Agent 能看到的信息，行动空间是能执行的操作"，但说不清如何平衡"完整性"和"简洁性"——观察太多会干扰 LLM 决策（Lost in the Middle），行动太多会导致选择困难。答好了能展示你对 Agent 信息论的理解和设计能力。

2️⃣ 标准答

1. 观察空间（Observation Space）：Agent 能感知的信息

• 设计目标：让 Agent 获取"做决策所需的最小充分信息集"
• 内容层级：L0 系统信息：system prompt、可用工具列表、用户画像
• L1 对话信息：当前对话历史（最近 N 轮）
• L2 环境信息：工具返回值、RAG 检索结果、外部 API 状态
• L3 元信息：剩余步数、已消耗 token、当前成本 设计原则：
• 最小充分：只包含当前决策必需的信息。冗余信息会干扰 LLM 决策——研究表明 prompt 中无关信息增加 50%，决策准确率下降 8-12%
• 结构化：用统一格式（JSON/XML）组织信息，而非自然语言描述。LLM 对结构化信息的理解更准确
• 优先级排序：重要信息放在 prompt 的开头和结尾（首因效应 + 近因效应），中间放次要信息
• 动态调整：根据任务进度调整观察内容。规划阶段需要全局信息，执行阶段只需要当前步骤信息 工程实现：

`observation = {** "system": system_prompt, "available_tools": [tool_schemas], "conversation": last_5_messages, "tool_results": current_tool_output, "metadata": {"step": 3, "max_steps": 10, "tokens_used": 5000} }

组装成结构化 prompt

prompt = f"<system>{observation['system']}</system>\n<tools>{observation['available_tools']}</tools>\n..."`2. 行动空间（Action Space）：Agent 能执行的操作**

• 设计目标：让 Agent 拥有"完成任务所需的最小必要能力集"
• 行动类型：工具调用：调用外部工具（搜索、代码执行、API 调用）
• 文本生成：生成回复文本（最终答案或中间推理）
• 流程控制：请求人工帮助、终止任务、回退到上一步 设计原则：
• 正交性：工具之间不应有功能重叠。如果 search_web 和 search_knowledge_base 都能搜索，LLM 容易选错。解决方案：合并为一个 search 工具，通过参数指定搜索范围
• 原子性：每个工具做一件事。analyze_data_and_generate_report 应该拆分为 analyze_data + generate_report，让 LLM 能灵活组合
• 完备性：覆盖任务所需的所有操作。如果 Agent 需要"发送邮件"但没有 send_email 工具，它可能用 execute_python 来发邮件——绕过了安全控制
• 描述清晰：工具描述包含"做什么"、"什么时候用"、"参数说明"、"返回值格式"。LLM 根据描述选择工具，描述不清导致误选 行动空间大小的影响：
• 工具太少（<3）：Agent 能力不足，无法完成任务
• 工具适中（5-15）：最优范围，LLM 选择准确率 >90%
• 工具太多（>20）：选择困难，准确率下降到 70-80%。解决方案：工具路由——先用小模型选"工具类别"，再在大类中选具体工具

3. 观察-行动对齐设计

• 信息-能力匹配：观察空间提供的信息必须支持行动空间的决策。如果 Agent 有 investigate_stock 工具但观察空间不包含股票数据，工具形同虚设
• 反馈完整流程：每次行动的结果应该作为下一次观察的输入。tool_result 进入观察空间，Agent 基于新观察做下一步决策
• 上下文管理：观察空间和行动历史会随步数增长。需要上下文压缩策略——旧步骤的观察和行动用 LLM 摘要后替换原始数据

3️⃣ 答题模板（30 秒电梯版）

"观察空间设计目标'最小充分信息集'——L0系统信息+L1对话+L2环境+L3元信息，原则：最小充分（冗余信息降低准确率8-12%）、结构化（JSON格式）、首尾优先（首因+近因效应）、动态调整。行动空间设计目标'最小必要能力集'——原则：正交性（工具不重叠）、原子性（一个工具一件事）、完备性（覆盖所有操作）、描述清晰。工具数量最优5-15个（准确率>90%），>20个需工具路由。观察-行动需对齐：信息支持决策，结果反馈到观察。"

4️⃣ 高频追问 & 应对

追问 1：工具太多（>20个）导致选择困难，工具路由具体怎么实现？

两级路由：(1) 第一级：工具分类——将工具按功能分组（如"搜索类"、"代码类"、"通信类"），用 GPT-4o-mini 判断"用户请求需要哪类工具"。延迟约 200ms，成本 $0.001；(2) 第二级：类内选择——只把选中类别的工具（3-5个）的 schema 传给主 LLM。主 LLM 在小范围内选择，准确率恢复到 90%+。实现：在 LangChain 中用 MultiRouteChain 或自建 router prompt。实测：两级路由将 25 个工具的选择准确率从 72% 提升到 91%，延迟增加 200ms（可接受）。替代方案：RAG 选工具——把工具描述做 embedding，用户请求做 embedding，向量检索 top-5 相关工具。延迟更低（50ms）但准确率略低（86%）。

追问 2：你说观察空间要"最小充分"，但怎么判断什么是"充分"的？

两种判断方法：(1) 消融实验——逐步移除观察空间中的信息类别，看任务完成率是否下降。如果移除某类信息后完成率不变，说明该信息非必需。实测：移除"历史对话"后完成率下降 15%（必需），移除"剩余步数"后下降 2%（可选）；(2) LLM 自评——执行后让 LLM 评估"给定的信息是否足够做决策"。如果 LLM 频繁说"信息不足"，说明观察空间不够充分。注意：LLM 可能说"信息不足"只是为了推脱，需要交叉验证——如果 LLM 说不足但任务完成了，说明信息其实够用。生产中建议定期做消融实验（如每季度），因为任务模式变化可能导致"必需信息"变化。

追问 3：多 Agent 系统中，不同 Agent 的观察空间和行动空间怎么分配？

按角色分配：(1) Orchestrator——观察空间=全局任务+所有子任务状态，行动空间=分配任务给Worker+汇总结果。不直接调用业务工具；(2) Searcher——观察空间=用户查询+搜索工具列表，行动空间=search_web+search_kb+summarize。只做搜索不做执行；(3) Executor——观察空间=搜索结果+执行工具列表，行动空间=execute_code+call_api+send_email。只做执行不做搜索。关键原则：每个 Agent 的观察空间和行动空间是"正交"的——不重叠、不缺失。如果两个 Agent 的行动空间重叠（如都能发邮件），会导致冲突（两个 Agent 同时发邮件）。如果某个 Agent 的观察空间缺少必需信息（如 Executor 不知道用户偏好），会做出错误决策。

5️⃣ 避坑 · 常见错误答法

• ❌ "观察空间越大越好，给 Agent 更多信息" → ✅ "冗余信息干扰 LLM 决策——无关信息增加 50%，决策准确率下降 8-12%。观察空间应该'最小充分'而非'越多越好'。"
• ❌ "工具越多 Agent 能力越强" → ✅ "工具 >20 个时选择准确率下降到 70-80%。需要工具路由或工具分类。最优工具数量 5-15 个。"
• ❌ "所有 Agent 共享同一个观察空间和行动空间" → ✅ "多 Agent 系统中，每个 Agent 的观察空间和行动空间应该正交——不重叠（避免冲突）、不缺失（避免无能）。按角色分配是最佳实践。"

6️⃣ 简历呼应

• 如果你有 Agent 设计项目：从"观察/行动空间优化"切入，描述你做的消融实验和工具路由设计，给出数据（如工具选择准确率从 72% 提升到 91%）
• 如果你有 RL 背景：用"MDP（马尔可夫决策过程）"类比——观察空间 = 状态空间，行动空间 = 动作空间。核心差异是 LLM Agent 的状态是文本（非数值），需要 prompt 工程而非特征工程
• 如果你是校招无项目：用 LangChain 实现 3 种观察空间配置（全量/最小/动态），在相同任务上对比完成率和 token 消耗，写一篇博客分析 trade-off
• "LLM Agent Observation and Action Space Design" (Wang et al., 2024)
• "Tool Learning with Foundation Models" (Qin et al., 2023)
• "The Impact of Prompt Length on LLM Decision Making" (Liu et al., 2024)