面试题 · 评估
搜索「提示工程」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
你认为一个理想的AI Agent应具备哪些核心能力（如规划、工具调用、记忆、反思等）？结合当前主流Agent系统的表现，评估现有技术是否已达到这一理想状态，并说明理由。
| 能力 | 核心要求 |
|---|---|
| 规划（Planning） | 将复杂目标拆解为可执行的子任务，支持动态调整 |
| 工具调用（Tool Use） | 精准选择、调用外部工具，处理多模态输入输出 |
学习内容与项目面试，在同一条路上。
| 短期上下文记忆 + 长期知识/经验存储与检索 |
| 反思（Reflection） | 自我评估执行结果，识别错误并修正策略 |
| 多轮交互 | 与用户、环境、其他Agent持续协作 |
| 安全与边界 | 拒绝有害请求，行为可解释、可控 |
已相对成熟的领域
关键短板
典型案例对比
现有技术实现了**"能用的Agent"，距离"可靠的Agent"**仍有代差。
根本瓶颈在于：LLM作为推理引擎，其概率性本质与Agent所需的确定性执行存在内在张力。当前主流方案是"用工程补模型"（如强制JSON输出、重试机制、人工校验节点），而非真正的认知架构突破。
场景切入
假设你在做一个智能客服Agent，用户说‘帮我查一下上周的订单，然后写一封催货邮件’。它需要先查订单、再写邮件，中间还可能发现订单丢失，得重新规划。你觉得这样的Agent要具备哪些能力才能做好这件事？现在市面上那些Agent系统，比如AutoGPT，真能处理好吗？
层层追问
你觉得一个理想的Agent应该有哪些核心能力？……比如规划、记忆这些，你怎么看？……那现在主流Agent系统，像ReAct、LangChain这些，你觉得它们在这些能力上做得怎么样？有没有什么明显短板？
直球架构
直接说说，你认为一个理想的AI Agent应该具备哪些核心能力？从规划、工具调用、记忆、反思这几个维度，再结合当前主流Agent系统的实际表现，评估一下现有技术离理想状态还有多大差距，理由是什么。
这道题其实问的是，在LLM作为推理引擎的大前提下，[[Agent]]的认知架构到底能推到什么程度，哪些能力是模型自己能搞定的，哪些必须靠工程手段补。我倾向于从两个维度来拆：一个是理想Agent该有的能力谱系，另一个是现有技术到底卡在哪。
先说理想状态。我自己梳理了六项核心能力，规划、工具调用、记忆、反思、多轮交互、安全边界。但真正落地时，我不会一把抓，而是看场景挑重点。比如做一个客服退款Agent，工具调用和短期记忆是刚需，规划反倒没那么复杂，因为流程相对固定；但如果做一个企业级数据分析Agent，那规划能力和长期记忆就变成了核心瓶颈。所以这里有个边界划分：规划适合有明确子任务拆解的场景，而工具调用更依赖接口稳定性和模型对工具的语义理解，两者不是替代关系，是互补。
具体到现有技术的表现，工具调用这块已经相对成熟了，OpenAI的[[Function Calling]]和Claude的工具使用，格式遵循率很高，配合[[ReAct]]框架基本能跑通。但一涉及到多步规划，问题就出来了。比如让Agent执行一个五步以上的任务，ReAct或[[Chain-of-Thought]]很容易出现错误累积，一步错步步错，最后要么死循环要么胡言乱语。AutoGPT就是个典型，早期喊得很响，实际用起来循环调用、成本失控、无法终止，根本落不了地。
记忆这块，短期记忆靠上下文窗口，现在大模型能做到128K甚至1M tokens，基本够用。但长期记忆是个硬伤，现在普遍用[[Vector Database]]做[[RAG]]，检索精度有限，而且缺乏真正的经验学习。比如一个Agent今天处理了某个退款案例，明天遇到类似情况它不会自动复用昨天的经验，除非你显式把案例写进提示词或向量库里。说白了，现在的长期记忆更像是一个外部存储，而不是Agent自身认知的一部分。
反思能力就更虚了。很多方案号称能做自我反思，但我观察下来，大部分是“伪反思”，模型只是生成一段自我批评的文本，比如“我错了，我应该先调用查询接口再调用退款接口”，但下次执行时它并不会真的修正策略，因为反思没有沉淀到行为层。真正有效的反思应该像[[Self-Refine]]那样，让模型基于执行反馈动态调整后续动作，但这在工程上很难做，因为反馈信号往往不连续、不结构化。
所以我的核心判断是：现有技术能做出“能用的Agent”，但离“可靠的Agent”还有代差。根本原因是LLM的概率性本质和Agent需要的确定性执行之间存在内在张力。现在主流的做法是用工程补模型，比如强制JSON输出、重试机制、人工校验节点，这些都是治标不治本。
说到反思，我最近在关注一个方向叫[[Self-Consistency]]和Self-Refine的结合，就是让模型生成多个推理路径然后选最优，再基于执行结果做二次修正。但这里有个前提：修正后的动作必须能回溯到原始规划里，否则修了这一步下一步又错了。这个方向目前还比较早期，但我觉得如果能打通，可能会让Agent的可靠性上一个台阶。
总的来说，我不会把Agent看作一个全能的系统，而是会根据业务场景做取舍。比如做客服Agent，我优先保证工具调用的准确率和短期记忆的上下文完整性，规划只做一层直接跳转；做复杂任务Agent，我会把重心放在规划拆解和错误恢复上，甚至允许人工介入做兜底。说白了，工程上能落地的Agent，往往是做了很多减法之后的产物。