面试题 · Agent
搜索「提示工程」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
为了更好地支持AI Agent的能力构建（如任务分解、工具调用、环境交互等），你认为基础大模型在架构设计、训练目标或输出格式上应做出哪些针对性优化？
原生支持结构化输出
工具感知嵌入
状态管理模块
学习内容与项目面试，在同一条路上。
多阶段课程学习
强化信号设计
| 组件 | 设计 |
|---|---|
| 规划输出 | 子任务DAG或线性序列，含依赖关系 |
| 工具调用 | 严格JSON，支持批量并行调用 |
| 执行反馈 | 统一错误码：工具失败/参数非法/环境异常 |
| 自我修正 | 显式的"反思"token触发重规划 |
场景切入
假设你要做一个AI订票助手，用户说‘帮我订明天去北京的机票，然后订个酒店’，它得先拆任务、调API、再根据反馈调整。你觉得基础大模型在架构或训练上要怎么改，才能更好支持这种工具调用和任务规划？
层层追问
现在大模型做Agent主要靠提示词驱动，你觉得够用吗？……如果不够，模型本身需要做什么变化？……比如输出格式、训练数据，或者模型结构上有什么要优化的？
直球架构
要让大模型原生支持Agent能力，比如任务分解、工具调用、环境交互，你觉得在模型架构、训练目标和输出格式上分别需要做哪些针对性优化？请从这三个方向具体讲讲设计思路。
这道题其实在问，当我们想让大模型真正去执行任务、调用工具、和环境交互的时候，现有的通用模型到底缺什么，以及怎么从模型本身去补。我理解核心思路是，不能指望纯对话模型靠提示词就变成[[Agent]]，需要在架构、训练、输出格式上做系统性优化。
先说架构层面。最本质的改动是让模型原生支持结构化输出。通用模型输出自由文本，但Agent需要的是能被程序直接解析的指令，比如JSON格式的工具调用。我在实际场景中会这么做：在输出层加一个专门的JSON head，或者用类似Outlines库的解码策略，在生成时就约束格式。更重要的，是引入“思考-行动-观察”这种三段式结构，就像[[ReAct]]范式，用特殊token把推理和行动分开，这样模型不会把“我要调用API”和“API返回了什么”混在一起。
还有一个关键点是工具感知。你不能每次把工具描述写在提示词里，那样上下文会爆炸。我的做法是把工具描述编码成可学习的tool [[embedding]]，和输入做交叉注意力，这样模型能动态理解当前有哪些工具可用。更激进一点，支持动态工具注册，推理时把新工具描述塞进上下文，模型就能[[零样本]]调用，不需要重新训练。
再说训练目标。这里有个明显的课程设计思路。第一阶段先强化通用推理，比如数学、代码、逻辑，这是基础。第二阶段用大量合成数据教模型工具调用的格式，比如给一段工具描述，让模型输出正确的调用JSON。第三阶段才上真实环境，让模型端到端执行任务，用环境反馈做强化学习。这个阶段的reward要细化，不能只看最终任务完成率，还要看子目标达成、工具调用合法性、执行效率。举个例子，一个客服退款Agent，任务分解成“查订单状态-验证退款规则-发起退款”，每一步都要有reward，否则模型可能跳过验证直接退款，出风险。
输出格式这块，我倾向于标准化。规划输出用子任务DAG，工具调用严格JSON，支持批量并行。执行反馈统一错误码，比如工具失败、参数非法、环境异常。这里有个坑：模型出错后怎么自我修正？我会加一个显式的“反思”token，触发重规划，而不是让模型继续在错误的路径上死磕。
最后说权衡。过度优化Agent能力会损害通用对话能力，所以专用训练数据占比我建议控制在30%以内。另外，复杂规划会增加推理步数，延迟会高，可以用投机解码或者[[蒸馏]]一个小模型做快速路由，简单任务走小模型，复杂任务才走大模型。
其实还有一个更前沿的方向，就是让模型在训练时就学会规划，比如用[[Tree-of-Thoughts]]数据做[[SFT]]，但这对数据质量和计算资源要求很高，落地时我会先评估收益是否值得。
所以我的结论是，基础模型为Agent优化不是堆功能，而是在结构化、工具感知、课程训练和标准化输出之间做取舍。我更倾向先做好格式标准化和工具感知，再逐步引入强化学习，而不是一上来就端到端训练。