一、Agent基础、架构1. ReAct、Plan-and-Execute、Reflection、Tree-of-Thought、Multi-Agent 如何对比模式核心思想优点局限ReActReasoning 和 Acting 交替简单、适合工具使用容易局部贪心Plan-and-Execute先制定计划再分步执行结构清晰适合长任务初始计划可能过时Reflection执行后自评和修正能从错误中恢复增加成本和延迟Tree-of-Thought多路径搜索和比较适合复杂推理成本高工程复杂Multi-Agent多角色协作适合专业分工协调成本和一致性问题实际系统常常混合使用简单任务ReAct。长任务Plan-and-Execute 动态重规划。高风险任务Reflection 人类确认。复杂研究或编码主 Agent 子 Agent 工具执行。2. AGENTS.md、Skills、Memory 文件作用类型解决问题生命周期AGENTS.md项目级通用指令随代码仓库长期存在Skill任务级专业能力按需加载和复用Memory个体/团队历史经验持续积累和更新3. 如何设计一个企业级 AI Agent 系统场景定义明确是客服、数据分析、研发提效、运营自动化、企业搜索还是流程审批。能力边界定义 Agent 能做什么、不能做什么、哪些动作需要人工确认。模型与路由简单任务用便宜模型复杂规划用强模型敏感任务走人工。工具和协议用 Function Calling 接业务 API用 MCP 接标准工具用 A2A 接远程专用 Agent。状态和记忆会话状态、任务状态、长期记忆、企业知识库分开管理。工作流编排确定性流程用 workflow开放任务用 Agent复杂流程用状态图。安全与权限RBAC、审批、沙箱、审计、数据脱敏、prompt injection 防护。评估与观测离线任务集、线上 tracing、人工反馈、失败样本回流。上线策略从只读建议模式开始再开放低风险工具最后逐步开放写操作。4. 如何避免 ReAct 陷入无效搜索和循环调用常见策略设置最大工具调用步数。对连续相同工具和相似参数做去重。要求每次 Action 前说明“本次工具调用将获得什么新增信息”。工具失败后必须改变查询策略而不是重复同一查询。对 observation 做摘要避免上下文污染。引入 evaluator 判断当前信息是否足够。对低收益工具调用设置成本惩罚。当多次失败时切换到 Plan-and-Solve、CoT-SC 或人工求助。如果 Agent 连续多轮没有获得新信息应触发 stop、replan 或 ask-human而不是继续消耗 token。5. Reflection / Reflexion 如何提升 Agent 可靠性Reflection 强调模型对自己的输出或行动进行检查和修正。Reflexion 更进一步把失败经验写入记忆用于后续尝试。适用于有明确成功/失败信号的任务常见流程Agent 执行任务。Evaluator 判断结果是否成功。如果失败Reflector 总结失败原因。将经验写入短期或长期记忆。下一轮执行时读取经验调整策略。一个好的 reflection应该具体到哪一步错了错误证据是什么下次不要重复什么应该尝试哪个新策略是否需要额外工具或信息。Reflection 不是越多越好优化建议只有失败、低置信度或高风险任务才触发反思。反思必须结构化失败原因、证据、修正策略、下步行动。反思写入长期记忆前要经过质量过滤。对同一问题设置最大反思轮数。反思要结合外部反馈例如测试结果、评测器、用户确认。6. 多 Agent 系统常见编排模式有哪些Supervisor一个上级 Agent 分配任务和汇总结果。Router根据输入类型选择最合适的 Agent。Swarm多个 Agent 自组织协作或交接。Debate多个 Agent 生成不同观点再由 judge 决策。Crew / Team角色固定的团队协作。Pipeline多个 Agent 按固定顺序处理任务。Blackboard多个 Agent 读写共享工作区。Market / BiddingAgent 根据能力声明竞争任务。实际工程里最常见的是 Supervisor、Router、Pipeline 和 Team因为它们可控、可观测、容易落地。二、Tool、MCP1. Agent 如何选择工具、调用工具并处理工具失败工具发现将当前可用工具、能力范围、参数 Schema 注入上下文或通过 MCP/tool search 动态发现。工具选择模型根据任务意图选择工具对于高风险工具先解释意图并等待授权。参数生成使用 JSON Schema 约束参数必要时让模型先生成计划再生成工具参数。执行与观测工具执行器返回结构化结果、错误码、stderr/stdout、资源链接或状态变更。失败恢复根据错误类型重试、换工具、缩小范围、请求用户输入或终止。结果验证检查是否满足目标例如测试是否通过、文件是否存在、数据库状态是否符合预期。工具失败分类参数错误让模型修正参数。权限错误请求用户授权或降级。环境错误提示依赖缺失。网络错误重试或换源。语义错误重新规划。安全错误停止执行。2. 工具 Schema 应该如何设计工具名清晰使用具体动词和对象例如 search_customer_orders 比 query 更好。描述强调适用边界不只写“查询订单”还要写“用于根据用户 ID 查询历史订单不用于创建或修改订单”。参数类型明确使用枚举、范围、必填字段、格式约束减少模型自由发挥。避免万能工具一个 execute_sql 或 run_shell 可以做很多事但风险很高。生产场景应封装成更细粒度业务工具。返回结构稳定返回结果应包含状态码、错误原因、关键字段、可展示摘要便于模型理解。错误可恢复错误信息要说明是参数缺失、权限不足、资源不存在、超时还是系统异常。安全边界内置Schema 不能代替权限系统。危险参数、越权资源、敏感字段必须由宿主系统拦截。3. MCP 和 Function Calling 的区别是什么Function Calling 是模型调用函数的能力MCP 是把工具和上下文服务标准化暴露给模型应用的协议。4. A2A 和 MCP 分别解决什么问题MCP 解决“Agent 如何使用工具和上下文”的问题。A2A 解决“Agent 如何和其他 Agent 服务通信协作”的问题。5. MCP Host、Client、Server 分别负责什么角色职责例子Host面向用户的 AI 应用负责模型、UI、权限和上下文总控IDE Agent、桌面 Agent、聊天应用ClientHost 内部的连接实例负责与一个 Server 通信每接一个 MCP Server 就有一个 ClientServer暴露工具、资源、提示模板和能力声明GitHub Server、Postgres Server、File Server交互流程Host 启动或连接 MCP Server。Client 与 Server 初始化连接并协商能力。Host 发现 Server 暴露的 Tools、Resources、Prompts。模型在需要时选择工具或读取资源。Client 把请求发给 Server。Server 执行操作或返回上下文。Host 把结果放回模型上下文。6. MCP Tools、Resources、Prompts 、Roots、Sampling、Elicitation有什么区别能力类比主要用途控制方Tools可执行函数执行动作、查询系统、调用 API模型通常可选择调用Resources可读取资料暴露文件、记录、数据库内容、上下文片段应用通常选择加载Prompts可复用提示模板提供任务模板、工作流模板、专家提示用户或应用选择使用Roots当前工作区、项目根目录、允许读取的路径Host 告诉 Server 当前可访问的边界SamplingMCP Server 需要模型帮助总结或推理Server 请求 Host 代为调用模型Elicitation工具执行前需要用户选择账号或确认参数Server 请求 Host 向用户补充信息7. MCP 的 stdio 与 Streamable HTTP 如何选择新版 MCP 中标准传输主要是 stdio 和 Streamable HTTP。旧的 HTTPSSE 传输用于兼容历史实现通常不建议新项目优先选择。传输工作方式适合场景注意事项stdioHost 启动本地子进程通过 stdin/stdout 交换 JSON-RPC 消息本地开发工具、CLI、文件系统、低延迟单用户场景权限继承宿主进程需限制可执行来源Streamable HTTPServer 作为 HTTP 服务支持远程连接和流式响应企业服务、云端工具、多用户部署、跨网络访问必须做认证、授权、TLS、审计和限流SSE旧版 HTTPServer-Sent Events 路线兼容旧 MCP Server 新项目优先迁移到 Streamable HTTP8. MCP Server 的工具粒度应该如何划分工具粒度要在“过细”和“过粗”之间平衡。推荐原则一个 Tool 对应一个清晰业务意图。读写分离例如 search_issues 和 create_issue 分开。查询类工具支持过滤、分页和字段选择。修改类工具支持 dry-run 或 preview。高风险工具需要显式确认字段例如 confirmtrue 不能由模型自动填充。对频繁组合使用的步骤可以封装为安全的复合工具。例如数据库 MCP 不应该只暴露 execute_sql而应优先暴露 list_tables、describe_table、query_readonly、run_approved_report 等更可控工具。9. MCP 如何处理认证、授权和凭证安全MCP 的安全设计要区分三层连接认证确认 Host / Client 是否可以连接 Server。远程 Streamable HTTP 场景通常需要 token、OAuth、mTLS、企业 SSO 或内网网关。用户授权确认当前用户是否有权访问某个资源或执行某个工具。例如同一个 MCP Server 下不同用户能看到的数据库、仓库、工单范围不同。工具级和参数级权限即使用户能连接 Server也不代表能调用所有工具、访问所有参数或执行所有副作用操作。凭证安全建议MCP Server 不应把 secret 返回给模型。使用短期 token 或代理凭证。对 OAuth scope 做最小权限控制。日志中脱敏 Authorization、cookie、API key、数据库连接串。对敏感操作记录审计日志。对远程 Server 使用 TLS。多租户 Server 必须做 tenant isolation。工具返回结果要做字段级脱敏。三、Memory、上下文工程1. 短期记忆、长期记忆、任务记忆、工具记忆如何区分记忆类型内容用途短期记忆当前对话、最近工具结果当前轮推理长期记忆用户偏好、项目约定、长期事实跨会话连续性任务记忆当前任务计划、进度、阻塞点长任务执行工具记忆工具可用性、参数经验、失败记录提高工具调用成功率团队记忆团队规范、共享知识多人/多 Agent 协作2. 上下文窗口溢出时如何处理常见策略滑动窗口仅保留最近的消息丢弃较早的内容。实现简单但容易丢失关键决策信息。摘要压缩将历史对话、工具结果、任务状态压缩成摘要。语义检索将历史消息和文件切片向量化按需检索。结构化状态把任务进度、TODO、约束、已完成动作保存为结构化对象。工具结果折叠长 stdout、搜索结果、文件内容只保留摘要和引用。分层上下文系统指令、任务目标、计划、相关文件、历史摘要按优先级拼接。子 Agent 隔离把探索性任务交给子 Agent主 Agent 只接收结论。四、Agent可观测性、测评1. Agent 可观测性和 tracing 应该记录什么Agent tracing 应记录用户输入。系统指令版本。模型调用参数。每次模型输出。工具调用名称、参数、结果、耗时。handoff 事件。guardrail 结果。权限审批记录。token、成本、延迟。错误和重试。最终输出。可观测性的目标Debug 为什么选错工具。复现失败案例。统计成本和延迟。做安全审计。构造评测数据集。持续优化 prompt、工具和策略。2. Agent 常用评测基准有哪些SWE-bench / SWE-bench Verified真实 GitHub issue 修复能力WebArena浏览器环境中的网页任务执行OSWorld操作系统/GUI 任务执行GAIA需要工具和多步推理的通用助理任务AgentBench多环境 Agent 能力τ-bench ”工具-用户-Agent 多轮交互和规则遵循HumanEval/MBPP “代码生成基础能力自建业务评测 企业流程、API 状态变更、规则合规生产评估不要只看一次成功率还要看passk 或多次运行稳定性。工具调用错误率。任务完成时间。成本。安全拒绝准确率。人工接管率。回滚率。