AI Agent开发必问技术问题

一、写在前面：为什么需要这份清单

最近帮几个团队面试 Agent 方向的候选人，发现一个规律：

能背出 ReAct 原理的人不少，能说清楚自己为什么选 ReAct 而不是 Plan-and-Solve 的人，十不存一。

这不是候选人的问题。市面上的面试资料太多把 Agent 当成新概念来”科普”，却没人告诉你：当你真正坐下来写代码、搭架构、上线运营一个 Agent 系统时，哪些技术问题是躲不掉的。

这篇文章我把自己踩过的坑、面试中反复追问的点、以及生产环境里的真实挑战，整理成一份”必问清单”。不是为了应付面试，而是为了让你在动手之前，想清楚那些决定成败的技术取舍。

二、第一问：规划（Planning）——Agent 的”大脑”真的够用吗？

2.1 ReAct 不是银弹

很多人上手 Agent 的第一件事，就是套一个 ReAct 框架。Thought → Action → Observation 循环，看起来很美。

但我在实际项目里遇到的问题是：ReAct 太容易陷入循环。

举个例子：让 Agent 查一个函数的用法。它搜索了一次，结果不够详细，于是再搜一次，还是不够详细，再搜……十轮之后，Token 烧完了，任务还没完成。模型不是在解决问题，是在”假装努力”。

2.2 你必须回答的三个问题

第一个问题：任务的确定性有多高？

• 如果每一步的输入输出都是可预期的（比如固定格式的数据处理），用Workflow（预定义流程）比 Agent 更稳定、更便宜。
• 如果每步都需要推理决策（比如开放式调研），才需要 Agent 的自主规划。

第二个问题：规划失败时怎么兜底？

• 设置最大步数限制（比如 15 步强制终止）。
• 每步检查是否偏离原始目标（目标对齐机制）。
• 规划失败时能否优雅降级到人工介入或简化流程？

第三个问题：规划的成本你能接受吗？

• ReAct 模式通常比直接调用多消耗 3-5 倍 Token。
• Plan-and-Solve（先规划再执行）能省一部分规划 Token，但牺牲了灵活性。
• 我的实战经验：简单任务用 Workflow，复杂任务用 ReAct + 步数上限，超复杂任务才上多 Agent 协作。

三、第二问：记忆（Memory）——Agent 为什么会”失忆”？

3.1 上下文窗口不是记忆

很多人以为把对话历史塞进 Prompt 就是记忆了。错。

上下文窗口是短期记忆，会话结束就清零。真正的 Agent 需要跨会话记住用户偏好、历史决策、成功经验。

3.2 三层记忆架构，你在哪一层踩坑？

我在项目里把记忆分成三层：

3.3 记忆设计的核心矛盾

存得越多，检索越慢；存得太少，Agent 越蠢。

我的做法是：
–自动摘要：每轮对话结束后，用模型提炼关键信息，而不是存完整对话。
–混合检索：向量检索负责”语义相似”，关键词检索负责”精确匹配”，两者结果合并排序。
–记忆优先级：用户明确说过的话 > Agent 推理出的偏好 > 通用领域知识。

四、第三问：工具（Tool Use）——为什么 Agent 总是”用错工具”？

4.1 工具描述是 Prompt 工程的一部分

Agent 选工具的依据，是你给它的工具描述（description）。描述写得模糊，Agent 就选错。

我踩过的坑：
–描述太抽象：”用于处理数据”——Agent 不知道什么数据、怎么处理。
–参数不明确：必填项没标出来，Agent 漏传参数，工具报错。
–返回值不说明：Agent 拿到结果不知道怎么用，只能瞎猜。

4.2 工具系统的”刚刚好”原则

工具设计有两个极端，我都踩过：

极端 A：万能工具

比如给一个Bash工具，什么都能干。问题是出错了你根本不知道哪一步错了。管道、重定向、子命令……错误信号在中间环节就被吞掉了。

极端 B：过度原子化

把每个功能都拆成独立工具，模型选工具时反而卡住。”都是找文件，用哪个？”选错一步，后面全乱。

我的三层设计：

4.3 MCP 协议值不值得跟进？

Anthropic 推的 MCP（Model Context Protocol）是个好事，标准化了工具接口。但 2025 年的现实是：生态还在早期，工具质量参差不齐。

我的建议：先把自己的核心工具打磨好，再考虑接入 MCP。工具链的稳定性比”标准化”更重要。

五、第四问：安全——Agent 能”做”的事越多，风险越大

5.1 Agent 安全 = LLM 安全 + 系统安全

LLM 本身的安全问题（幻觉、偏见、有害输出）Agent 全继承了，但 Agent 还有额外风险：

• 它能执行操作：调用 API、修改数据、发送消息。
• 它能循环执行：一个死循环的 Agent，可能在一分钟内把你的 API 配额烧光。
• 它能接触敏感数据：查询数据库、读取用户信息。

5.2 四层防护架构

我在生产环境里建了四层防护：

输入层：提示注入检测、敏感信息过滤（比如信用卡号、身份证号）。
决策层：高风险操作（删除、转账、发送邮件）必须人工确认；预算控制（单次会话 Token 上限）。
执行层：工具权限最小化（只读工具不给写权限）；操作审计日志（每一步留痕）。
输出层：内容安全审查、隐私信息脱敏。

5.3 一个真实的教训

有一次 Agent 在调试时误触了测试环境的”清空数据”接口。好在测试环境有快照，恢复了。但这件事让我加了一条铁律：Agent 永远不能直接接触生产环境的”写”接口，必须通过审批流。

六、第五问：可观测性——Agent 出错时，你怎么知道它错在哪？

6.1 黑盒 Agent 是运维噩梦

传统系统的错误链路：请求 → 服务 A → 服务 B → 数据库 → 返回。每一步都有日志，能追溯。

Agent 的错误链路：用户输入 → LLM 推理 → 工具调用 → LLM 再推理 → 再调用工具……中间每一步的”思考”都是黑盒。

6.2 可观测性的三个维度

Trace（追踪）：记录完整的 Thought-Action-Observation 链，可视化每一步的决策过程。

Metrics（指标）：Token 消耗、工具调用次数、任务成功率、平均步数、延迟分布。

Evaluation（评估）：自动评估 Agent 的输出质量（比如用另一个模型打分），而不是等用户投诉。

6.3 我的调试工具链

• LangSmith / Langfuse：可视化 Agent 的执行轨迹。
• 结构化日志：每一步输出 JSON，便于搜索和分析。
• 对抗测试：定期给 Agent 喂边界 case（模糊输入、错误工具结果、超长上下文），看它会怎么崩。

七、第六问：多 Agent 协作——什么时候才需要上多 Agent？

7.1 单 Agent 够用时，别上多 Agent

多 Agent 的通信开销、协调复杂度、调试难度，都是指数级增长的。我见过一个本可以用单 Agent + 几个工具解决的场景，硬拆成 5 个 Agent，结果三天两头出协作故障。

7.2 真正需要多 Agent 的场景

• 任务天然可拆分：比如”写报告” = 研究员 Agent（搜资料）+ 写手 Agent（写正文）+ 编辑 Agent（润色）。
• 需要多视角验证：比如”评估风险” = 乐观派 Agent + 悲观派 Agent + 中立派 Agent 投票。
• 安全隔离需求：敏感操作 Agent 和普通查询 Agent 分离，权限粒度不同。

7.3 多 Agent 架构的三种模式

八、第七问：人机协作——全自动不是目标，可控才是

8.1 过度自动化的问题

完全自动化的 Agent 让用户失去掌控感。你不知道自己账户里被做了什么操作，直到收到账单。

8.2 三种协作模式

Human-in-the-loop：每个关键步骤人工确认。适合高风险操作（金融、医疗）。

Human-on-the-loop：Agent 并行执行，异常时通知人工介入。适合批量处理。

Human-over-the-loop：全自动，事后审计。适合低风险高频任务（比如定时报表生成）。

8.3 我的设计原则

• 渐进式自动化：从人工确认开始，根据 Agent 的表现逐步放权。
• 置信度阈值：模型对结果不自信时，自动转人工。
• 优雅降级：Agent 遇到瓶颈时，无缝移交人工，而不是卡住或乱答。

九、写在最后：这份清单不是答案，是起点

Agent 技术还在快速演进，今天的主流方案（ReAct、RAG、MCP）明天可能就被取代。但这份清单里的问题——规划怎么设计、记忆怎么管理、工具怎么编排、安全怎么保障、出错怎么调试——是长期存在的。

面试时，与其背概念，不如拿一个你实际做过的 Agent 项目，从需求分析、架构设计、技术选型、踩坑记录、最终效果，完整讲一遍。这比任何八股文都更有说服力。

Agent 开发没有标准答案，只有最适合你场景的解法。

我是 YanG，一个在 AI 产品路上探索的产品经理。如果你觉得这份清单有帮助，欢迎收藏转发。