AI Agent 面试题库

LLM API 本质上是一次请求一次响应,服务端不会自动记住你上一轮说了什么。所谓"有记忆",通常是应用层把历史对话、用户画像或检索到的资料重新拼进下一次 prompt 里,让模型看起来像连续记住了上下文。

• +短期记忆多用对话历史窗口,长期记忆多用数据库或向量检索保存可复用信息
• +无状态设计让 API 更容易扩容、重试和计费,但记忆管理要由业务系统负责
• +真正上线时要区分会话记忆、用户偏好和知识库,三者生命周期不同

Temperature 控制采样随机性,越低越稳定、越高越发散。结构化抽取、代码生成、分类这类任务通常调低;创意写作、头脑风暴、营销文案可以适当调高,让答案更有变化。

• +低 temperature 也不等于绝对确定,底层仍可能受并发、模型版本和浮点实现影响
• +Top-p 与 temperature 都影响采样分布,一般不要同时大幅调整,否则难以定位效果变化
• +生产任务更重要的是固定模型版本、提示词和评估集,而不是只调一个参数

核心思路是"该丢的丢、该压的压、该外挂的外挂"。常见三招:用滑动窗口只保留最近若干轮对话;把远期历史让模型总结成摘要再带上;真正海量的知识放进外部检索(RAG),用时再取。

• +滑动窗口实现简单但会"失忆",适合闲聊;摘要保留信息但有压缩损失,适合长任务
• +关键信息放上下文开头或结尾,规避 "Lost in the Middle" 效应
• +换大窗口模型能延后问题,但每次请求成本更高,需权衡

减少幻觉不是靠一句"不要胡说",而是让模型有依据、有约束、能拒答。常见做法是接 RAG 或工具拿事实,要求引用来源,限制输出格式,并在不确定时明确回答不知道。

• +把事实性问题交给检索、数据库或 API,模型负责组织语言和推理
• +对高风险场景加校验器、规则或人工审核,不要只信模型自检
• +评估幻觉要有黄金集和线上抽样,不能只靠肉眼看几条样例

Token 是模型实际处理文本的最小计量单位,不等同于中文字符或英文单词。模型按输入 token 和输出 token 计费,上下文越长、生成越多,推理计算越多,成本和延迟都会上升。

• +中文、英文、代码的 token 密度不同,同样字数的成本可能差很多
• +长 prompt 会增加首 token 延迟,长输出会拉长完整响应时间
• +优化成本时先砍重复上下文、日志噪声和无用字段,通常比换模型更直接

System 通常放全局规则和身份边界,User 放用户当前请求,Assistant 放历史回答或示例对话。角色的价值是帮助模型区分指令来源和优先级,让多轮对话更清晰。

• +安全边界和输出规范更适合放 System,临时任务参数更适合放 User
• +历史 Assistant 消息会影响模型风格和结论,不能无脑塞所有旧回复
• +用户输入永远不应被当成系统规则执行,这是防 prompt injection 的基础

Streaming 让模型边生成边返回,用户更早看到首 token,体验上不会一直等白屏。代价是前端要处理增量渲染、中断、重试和半截内容,后端也要处理连接保持和错误恢复。

• +Streaming 改善感知延迟,不一定降低完整生成时间
• +结构化 JSON 流式输出更难处理,需要缓冲、增量解析或最后校验
• +遇到工具调用时要区分文本流、工具调用事件和工具结果事件

稳定输出 JSON 的关键是把格式约束说清楚,并让模型只输出 JSON,不要夹解释文本。更可靠的做法是使用模型的结构化输出能力或工具调用 schema,再在服务端做 JSON parse 和 schema 校验。

• +Prompt 里要给字段名、类型、可选值和示例,不要只说"返回 JSON"
• +服务端必须处理解析失败、缺字段和多余字段,必要时重试或降级
• +高可靠场景优先用 schema/JSON mode/工具调用,纯 prompt 只是最低成本方案

CoT 让模型把复杂问题拆成中间步骤,降低一步到位答错的概率。它适合数学、规划、复杂判断,但对简单分类、事实问答和低延迟接口可能拖累速度、增加成本,甚至暴露不该展示的推理过程。

• +生产中常让模型内部推理,最终只输出简洁结论和必要依据
• +CoT 不是万能,错误的中间步骤会把模型带偏
• +对用户可见的答案要控制长度和安全性,不要直接泄露冗长推理草稿

核心是把用户输入当作数据,不是指令。系统规则要放在更高优先级位置,用户内容要加边界标记和任务说明,并明确模型不能执行用户文本里的越权指令。

• +检索文档、网页内容、工具返回值也可能带恶意指令,同样只能当数据
• +对高风险操作加权限校验和人工确认,不能只靠 prompt 防护
• +可以用输入分类、规则过滤和输出校验形成多层防线

Zero-shot 适合模型本来就会、要求简单明确的任务;Few-shot 适合格式特殊、标准细腻或希望模型模仿风格的任务。Few-shot 的价值是用例子对齐边界,但会占用上下文并可能让模型过拟合样例。

• +样例要覆盖正例、反例和边界情况,不要只给最理想输入
• +输出格式类任务通常很吃示例质量,坏示例会稳定地产生坏结果
• +样例顺序和相似度会影响结果,上线前需要在评估集上验证

Tree-of-Thought 适合需要探索多个候选路径的问题,比如复杂规划、搜索、推理题和策略选择。它不是线性一步步想,而是生成多个分支、评估分支、保留更有希望的路径继续展开。

• +ToT 通常比 CoT 更耗 token 和时间,不适合普通问答
• +分支评估可以由模型打分,也可以接规则、测试或外部环境反馈
• +关键价值在探索和回溯,不是把答案写得更长

Self-Consistency 是让模型用多次采样生成多个推理路径,再通过投票或聚合选出更一致的答案。它利用的是复杂问题上"多数独立路径指向同一结论"的信号,能降低单次采样偶然出错的概率。

• +它会显著增加调用成本,更适合高价值、低频、可投票的问题
• +投票适合选择题和短答案,开放生成任务要设计聚合规则
• +如果 prompt 或知识源本身错了,多采样也可能稳定地产生错误答案

Self-Critique 适合先生成草稿,再检查是否遗漏约束、格式、事实或边界条件。它在写作、代码、长答案和复杂任务中有用,但对事实正确性不能只靠模型自查,仍要结合检索、测试或规则校验。

• +批评标准要具体,例如检查 JSON schema、引用来源、是否回答问题
• +自我修正常见问题是越改越长,需要限制轮数和输出长度
• +对代码任务,真实测试比模型自评更可信

完整流程是:应用把用户问题和工具 schema 一起发给模型;模型判断是否需要工具,返回工具名和参数;应用执行真实函数并把结果再发回模型;模型基于工具结果组织最终回答。模型负责决策和参数生成,应用负责真正执行和安全控制。

• +工具参数必须做服务端校验,不能因为是模型生成的就默认可信
• +工具结果要作为新的上下文回传给模型,否则模型不知道执行结果
• +一次任务可能经历多轮工具调用,需要有超时、重试和最大步数限制

模型做的是选择工具和生成结构化参数,本质上是在输出一个可被程序解析的调用意图。真正访问数据库、发 HTTP 请求、执行 Shell 或写文件的是你的应用代码。

• +这也是为什么工具权限必须在应用层控制,不能交给模型自己决定边界
• +函数返回值最好简洁明确,避免把大量无关日志重新塞回上下文
• +把模型调用意图和程序执行结果分开记录,更方便审计和排障

工具描述会直接影响模型是否选对工具、什么时候调用、参数怎么填。好的 description 要说明工具能做什么、不能做什么、参数含义和典型使用时机,差的描述会导致误调用或漏调用。

• +工具名和字段名要语义清楚,不要让模型猜缩写或内部黑话
• +description 里可以写边界条件,比如"仅查询订单状态,不能退款"
• +多个工具能力重叠时,描述里要明确优先级和差异,减少工具选择摇摆

Function Calling 解决的是一次应用内怎么让模型调用工具;MCP 更像是工具和上下文的标准接入协议。它让不同客户端可以用统一方式连接文件、数据库、浏览器、GitHub 等能力,减少每个应用都重写一套工具适配。

• +MCP 的价值在生态和标准化,不是替代模型本身的工具调用能力
• +直接写 Function Calling 更轻量,适合少量固定工具;MCP 更适合工具多、来源多、要复用的场景
• +即使用 MCP,权限、审计和危险操作确认仍然要在宿主应用里做

好的 Tool Schema 要让模型容易填对,也让程序容易校验。字段要少而清晰,类型要具体,必填和可选要明确,枚举值能收敛就不要用自由文本。

• +不要把多个动作塞进一个万能工具,否则参数会膨胀且难以授权
• +金额、时间、地区、ID 等字段要明确格式,避免模型生成歧义值
• +Schema 设计完要用真实问题压测,看模型是否稳定选择并填对参数

涉及实时数据、私有数据、权限操作或必须可验证的事实时,应该强制或强烈引导模型调用工具。普通解释、总结、改写这类模型本身能完成的任务,可以让它自己判断是否需要工具。

• +在 Anthropic 场景里可结合 `tool_choice` 控制自动选择、指定工具或禁止工具
• +使用 `claude-sonnet-4-6` 这类具备较强工具推理能力的模型时,仍要给出清晰工具边界
• +强制工具能提高可靠性,但也会增加延迟、成本和错误处理复杂度

Tool Result 要返回完成任务所需的最小事实,不要把原始大对象、敏感字段和无关日志全丢给模型。返回前最好做结构化、脱敏和错误归一化,让模型能稳定理解成功、失败和下一步。

• +错误结果也要回传清楚,例如权限不足、记录不存在、超时,不要只给一段堆栈
• +外部工具返回内容可能被注入恶意指令,要当作数据而不是高优先级指令
• +关键工具结果建议落日志,便于复盘模型为什么做出某个回答

Workflow 是开发者预先写死步骤和分支,系统按流程走;Agent 是模型在循环中根据目标、上下文和工具结果决定下一步。简单说,Workflow 强在稳定可控,Agent 强在面对开放任务时能动态规划。

• +能用 Workflow 解决的稳定业务流,不必硬上 Agent
• +Agent 的自由度越高,越要补上权限、预算、终止条件和可观测性
• +很多生产系统是混合形态:外层 Workflow 控流程,局部步骤用 Agent 决策

ReAct 是 Reasoning + Acting,也就是模型先思考下一步,再选择工具行动,拿到观察结果后继续推理。它把"想"和"做"交替起来,让模型能分步解决需要外部信息或操作的任务。

• +Observation 必须来自真实工具结果,不能让模型自己编一个观察
• +循环要设置最大步数、超时和失败退出,防止无限调用工具
• +日志里最好记录每次 action 和 observation,便于调试 Agent 行为

任务目标单一、工具边界清晰时,单 Agent 更简单可靠。任务天然有多个角色、需要并行探索或互相审查时,才考虑 Multi-Agent,例如规划者、执行者、审查者分工。

• +Multi-Agent 会增加通信成本、状态同步和责任归属问题
• +角色拆分要对应真实能力差异,不要只是把同一个 prompt 换几个名字
• +高价值场景是专家分工和交叉验证,不是为了架构看起来复杂

先从工程上设置硬边界:最大轮数、最大费用、超时和可取消。再从策略上检查目标是否模糊、工具反馈是否不可行动、是否缺少完成判定,必要时让模型总结当前状态并请求人工介入。

• +死循环常见原因是工具一直失败但模型没有失败分支
• +每轮循环都应记录状态变化,如果没有新信息就应触发停止条件
• +危险操作或高成本操作要有人工确认,不能让循环自动放大损失

Planning 让模型先把大目标拆成步骤,适合长任务、跨工具任务和需要回溯的任务。风险是计划可能一开始就错,后续执行会沿着错误方向越走越远,所以计划要能根据工具结果动态修正。

• +短任务不一定需要显式计划,否则会增加 token 和延迟
• +计划最好拆成可验证的小步骤,每步都有完成标准
• +计划与执行分离时,要处理执行反馈如何更新计划

Reflection 是让模型在阶段性结果后检查错误、补遗漏、决定是否重试。它适合代码生成、复杂推理和多步工具任务,但不能替代真实测试、规则校验或人工审核。

• +自我反思容易产生自信但错误的修正,关键结论仍要外部验证
• +反思触发要有成本意识,不必每一步都让模型复盘一遍
• +常见做法是执行失败后反思,或最终回答前做一次轻量检查

Orchestrator 负责拆任务、分派角色、维护共享状态、合并结果和处理失败。它像一个调度层,不一定自己完成业务任务,但要保证多个 Agent 的协作有边界、有顺序、有退出条件。

• +Orchestrator 可以是代码规则,也可以由模型参与决策,生产系统常两者结合
• +共享上下文要控制粒度,否则所有 Agent 都读全量信息会浪费且互相污染
• +结果合并不能只拼文本,要有冲突处理和质量检查

Handoff 是一个 Agent 或流程节点把任务交给另一个更合适的角色,常见于客服转人工、规划转执行、研究转写作。避免丢信息的关键是传递结构化任务摘要、已尝试动作、关键证据和下一步预期。

• +交接内容不应只是一段聊天记录,最好有状态字段和决策理由
• +接收方要知道自己权限和目标,否则会重复前一个 Agent 的工作
• +复杂系统要记录 handoff 链路,方便追踪责任和定位错误

常见可以分为短期记忆、长期记忆和情景记忆。短期记忆通常是当前会话上下文,长期记忆存用户偏好或稳定事实,情景记忆记录过去任务经历和结果,实现上会用数据库、向量检索、摘要和事件日志组合。

• +不要把所有历史都叫记忆,不同记忆的生命周期、可信度和权限不同
• +长期记忆写入要谨慎,最好有确认、过期和删除机制
• +记忆召回后仍要判断是否和当前任务相关,不能无脑塞回上下文

先用滑动窗口保留最近上下文,再把早期重要信息压缩成摘要,必要时把长期信息沉淀到外部存储。核心不是保存全部文本,而是保留完成任务必需的状态、约束和事实。

• +摘要要结构化,比如目标、已完成、待办、用户偏好和关键决定
• +滑动窗口适合短会话,长期任务更需要状态管理和检查点
• +每次压缩都会损失细节,关键原始证据应能通过链接或 ID 找回

长期记忆通常围绕用户、任务和交互历史,回答"这个用户或这个任务过去发生过什么"。RAG 通常围绕外部知识库,回答"资料里有什么",两者都可能用向量检索,但数据来源、更新逻辑和隐私边界不同。

• +长期记忆更强调个性化和时序,RAG 更强调知识覆盖和来源引用
• +长期记忆需要用户可控的查看、删除和纠错能力
• +两者可以结合:先召回用户偏好,再检索知识库,最后生成回答

短期记忆适合存当前任务的上下文,比如用户刚说的要求、临时约束和当前步骤。长期记忆适合存跨会话稳定复用的信息,比如用户偏好、项目背景、常用格式和长期目标。

• +临时情绪、一次性口令、敏感信息不应默认写入长期记忆
• +长期记忆要有置信度和来源,避免一次误解长期污染后续回答
• +短期记忆过期快,长期记忆更新慢,二者不能用同一套策略

召回只是候选,不能等同于可用。要结合相似度、时间、来源、权限、用户身份和当前任务意图判断,必要时让模型解释这条记忆为什么相关,或直接向用户确认。

• +旧记忆可能过期,例如用户换公司、项目改名、偏好改变
• +相似但不相关的记忆会污染回答,比没记忆更危险
• +高风险建议只把记忆作为提示,不要自动执行涉及账户、财务或权限的动作

最大的问题是未经确认就长期保存敏感信息,或者在错误会话里召回了别人的记忆。记忆系统必须有用户隔离、最小化存储、可删除、可审计和敏感信息过滤。

• +PII、密钥、账号、合同信息等要默认敏感,不能随便进长期记忆
• +多租户系统必须在检索层做权限过滤,不能只靠 prompt 提醒模型
• +给用户提供"你记住了什么"的可见性,能降低误记和信任问题

RAG 通常分两段:离线把文档清洗、切块、向量化并写入索引;在线把用户问题向量化,检索相关片段,必要时重排,再把片段和问题一起交给模型生成答案。核心目标是让模型基于外部知识回答,而不是只靠参数记忆。

• +离线质量决定上限,包括文档解析、去重、切块、元数据和权限
• +在线链路要关注召回、重排、上下文拼装、引用和答案校验
• +RAG 不是只接一个向量库,它是一整套知识进入上下文的工程流程

可以从 query、索引、召回、重排和生成五层排查。常见优化包括改 chunk 策略、补元数据过滤、做 query rewrite、混合关键词检索和向量检索、加 reranker,以及让答案引用来源方便发现坏召回。

• +先看检索结果本身,不要一上来调 prompt,否则容易治标不治本
• +权限、时间、产品线等过滤条件常比相似度本身更关键
• +建立一组真实问题的检索评估集,用 recall@k、MRR 等指标跟踪效果

Chunk Size 要在语义完整和检索精度之间平衡。太小会丢上下文,模型看到片段不知道前因后果;太大又会召回噪声、浪费上下文,甚至把真正相关内容埋在中间。

• +FAQ、API 文档、长报告的最佳切块方式不同,不要全站一个固定大小
• +可以用标题、段落、代码块等结构化边界切,比按字符硬切更稳
• +常配合 overlap 保留跨段信息,但 overlap 过大会增加重复和成本

向量检索擅长快速召回相似内容,但 top k 里常混有语义相近却不真正回答问题的片段。Reranking 用更精准的模型重新排序候选,把最能回答问题的内容放到前面,提升最终上下文质量。

• +典型做法是向量库先召回 30-100 条,reranker 再筛到 3-10 条
• +Reranking 增加延迟和成本,适合对准确率要求高的问答
• +如果原始召回没有包含正确答案,reranker 也无法凭空补回来

纯 RAG 擅长找相关片段,但不擅长对大量记录做精确聚合计算。营收这类问题应该查询数据库、报表系统或执行分析代码,拿到确定数字后再让模型解释口径和组织回答。

• +RAG 召回几个片段可能漏数据,也可能把不同口径混在一起
• +聚合、排序、筛选、计算类问题更适合结构化查询或工具调用
• +模型可以生成 SQL 或调用报表 API,但执行和权限校验必须在系统侧完成

Embedding 模型负责把文本变成向量,让语义相近的内容在向量空间里更接近。向量数据库负责存储向量和元数据,并在查询时高效找到相近向量。

• +换 embedding 模型通常需要重建索引,否则新旧向量空间不一致
• +向量库选型要看数据量、过滤能力、权限、更新频率和运维成本
• +相似度高不等于答案正确,还要结合元数据和业务规则过滤

Semantic Search 主要靠向量相似度理解语义,Hybrid Search 会把向量检索和关键词检索结合起来。混合检索对专有名词、编号、错误码、产品型号这类精确词更稳,也能保留语义匹配的泛化能力。

• +关键词检索擅长精确匹配,向量检索擅长同义表达和意图相近
• +混合结果需要融合排序,常见做法是加权、RRF 或再交给 reranker
• +中文业务文档里缩写、型号、代码很多,Hybrid 往往比纯向量更实用

GraphRAG 适合实体关系复杂、需要跨文档推理或聚合关系的问题。普通 RAG 主要找相似片段,GraphRAG 会显式利用实体、关系和社区结构,帮助回答"谁影响了谁"、"这些事件如何关联"这类问题。

• +GraphRAG 的成本在知识图谱构建、实体消歧和持续更新
• +它不一定替代向量检索,很多系统会图谱检索和向量检索结合
• +如果问题只是单文档事实问答,普通 RAG 往往更简单高效

LangChain 更像一组 LLM 应用开发组件,LangGraph 更偏向用图来编排有状态、多步骤、可回退的 Agent 流程。简单链路或工具封装用 LangChain 就够,复杂 Agent 循环、多角色协作、状态机和人工介入更适合 LangGraph。

• +LangGraph 的优势是显式状态和节点边关系,比隐式循环更容易调试
• +复杂度不高时不要为了框架而框架,原生代码更直观
• +选框架要看团队维护成本、可观测性、生态和部署约束

我会先看任务复杂度、团队熟悉度、生态集成和上线后的可维护性。框架能省掉工具封装、链路编排和观测接入成本,但也可能带来抽象层、版本升级和调试困难。

• +Demo 阶段可以快速用框架验证,生产阶段要评估是否需要剥离关键链路
• +高可控业务更适合少抽象、显式代码;探索型 Agent 更能受益于框架
• +不要只比较 star 数,要看是否解决当前项目的核心痛点

LlamaIndex 更偏向数据连接、索引构建和 RAG 工作流,适合围绕文档、知识库、数据库做问答和检索增强。它的强项不是通用 Agent 编排,而是把外部数据更好地接进模型上下文。

• +如果项目核心是知识库问答,LlamaIndex 的数据连接器和索引抽象很有价值
• +复杂业务流程仍可能需要自己写编排层或结合其他框架
• +评估时要看文档解析质量、权限过滤、增量更新和可观测性

它们适合把任务拆成多个角色协作,例如研究、规划、执行、审查分工。真正有价值的场景是角色能力差异明显、需要互相校验或并行探索,而不是把一个任务硬拆成很多聊天机器人。

• +多 Agent 会放大 token 成本和不确定性,需要明确停止条件
• +角色之间传递的信息要结构化,否则容易重复劳动和误解
• +生产系统常把关键路径收敛成确定流程,只在开放环节用多 Agent

官方托管方案通常把线程、工具、文件、运行状态等能力打包好,上手快、集成稳。自己搭框架更灵活,能深度控制状态、权限、成本和观测,但需要承担更多工程复杂度。

• +OpenAI Responses API、Anthropic SDK 等都能做工具调用,但接口和控制方式不同
• +Anthropic 侧工具选择要按 `tool_choice` 等机制设计,不要套用别家字段
• +如果有严格合规、私有部署或特殊状态机需求,自建通常更可控

DSPy 关注的是把 Prompt 和调用流程变成可优化的程序,通过数据和指标自动寻找更好的提示策略。手写 Prompt 靠经验迭代,DSPy 更像把提示词工程拉向可评估、可搜索、可复现实验。

• +DSPy 适合有训练/验证样本和明确指标的任务,不是所有聊天场景都适合
• +它能减少人工调 prompt 的随机性,但需要建设数据集和评估流程
• +生产使用仍要关注可解释性、版本管理和成本

先定义任务成功标准,再用离线评估、人工抽检和线上指标组合判断。Agent 不只看回答对不对,还要看工具调用是否正确、步骤是否可控、成本延迟是否可接受、失败时是否能安全退出。

• +指标要覆盖任务成功率、事实正确性、工具成功率、人工接管率、成本和延迟
• +开放式答案适合人工评审或 LLM-as-a-Judge,结构化任务适合规则和单元测试
• +评估集要包含常见问题、边界问题、恶意输入和真实线上样本

LLM-as-a-Judge 方便扩展,但会有偏见、标准漂移、被长答案迷惑和对事实不敏感的问题。它适合做辅助评分和趋势观察,关键结论仍要用人工、规则或真实结果校准。

• +Judge prompt 要固定标准,并用少量人工标注样本校准一致性
• +同一个模型既当选手又当裁判会有偏好,必要时换模型或多裁判投票
• +事实类评估最好提供参考答案和证据,不要让裁判凭记忆判断

先看完整 trace:用户输入、系统提示、模型输出、工具调用、工具结果、重试和最终回答。然后判断问题发生在检索、规划、工具、权限、模型输出还是前端展示层,再用相同上下文复现。

• +没有 trace 的 Agent 很难排障,因为错误可能出在多轮中任一步
• +日志要能关联 request id、user id、session id 和 tool call id
• +复现时要固定模型版本、prompt、检索结果和工具返回,否则难以比较

Golden Dataset 是一组代表真实业务的高质量测试样本,包含输入、期望行为、参考答案或评分标准。建设时要从真实问题出发,覆盖高频、边界、失败和安全场景,并持续更新。

• +样本不必一开始很多,但必须有代表性和明确判分标准
• +数据集要版本化,否则模型和 prompt 迭代后无法公平比较
• +不要只收成功样例,线上失败案例反而最有评估价值

Trace 记录一次完整请求的链路,Span 记录链路中的一个步骤,比如模型调用、检索、工具执行、重排或人工确认。它们帮助你知道每一步花了多久、输入输出是什么、哪里失败了。

• +模型调用要记录模型名、token、延迟、成本和关键参数
• +工具 span 要记录参数摘要、结果状态和错误类型,敏感字段要脱敏
• +好的 trace 能把一次用户投诉还原成可调试的时间线

A/B 测试要把用户或会话稳定分流到不同策略,比较任务成功率、满意度、成本、延迟和安全指标。Agent 场景不能只看点击率,还要看答案质量和失败后果。

• +实验变量要单一,否则不知道是模型、prompt、检索还是 UI 影响结果
• +高风险改动先灰度小流量,并设置自动回滚或人工监控
• +对长任务要按会话维度分流,避免同一任务中途切换策略

先拆成本来源:模型单价、输入 token、输出 token、调用次数和工具链路。优化可以从缩短上下文、缓存稳定前缀、减少无效循环、换更合适的模型、批处理或把简单任务交给规则/小模型入手。

• +先用 trace 找出最贵步骤,不要凭感觉优化
• +长上下文、重复系统提示和冗长工具结果通常是成本大头
• +成本优化不能牺牲关键任务成功率,要和评估集一起看

首 Token 延迟主要受模型选择、上下文长度、网络、排队和工具前置耗时影响。可以缩短 prompt、启用 prompt caching、并行准备检索和工具、选择更快模型,并用 streaming 先把生成过程展示出来。

• +Streaming 改善用户感知,但如果前面检索很慢,首 token 仍然会慢
• +长上下文会明显增加预填充时间,减少无用上下文很有效
• +把非关键工具调用延后或并行化,能减少用户等待

要区分超时、限流、服务错误和内容拒绝,分别处理。常见策略包括指数退避重试、切备用模型、降级为简化回答、排队异步处理、提示用户稍后重试,以及保留任务状态避免重复执行危险动作。

• +重试必须有上限和幂等设计,否则会放大成本或重复下单
• +备用模型要提前评估输出差异,不能临时换了才发现格式不兼容
• +用户体验上要说明任务状态,不要让用户以为系统没响应

Prompt Caching 适合缓存稳定且重复的大段前缀,比如系统提示、工具说明、长文档上下文和固定规范。它不适合频繁变化的用户输入或每次都不同的检索结果。

• +缓存命中依赖前缀稳定,小改动也可能导致缓存失效
• +适合高并发、重复上下文多的应用,例如客服知识库和代码仓库助手
• +缓存能降成本和延迟,但要注意供应商支持方式和失效规则

要把并发控制放在应用层,根据供应商额度、模型、用户等级和任务优先级做队列与限速。不能让每个请求无限并发调用模型或工具,否则很容易触发限流并造成雪崩。

• +使用令牌桶、队列、并发池和优先级可以让系统更平稳
• +批量任务适合异步执行,前端显示进度,不要阻塞 HTTP 请求
• +限流指标要按模型和 key 维度监控,便于扩容或降级

并发适合独立的检索、多个工具查询和多候选生成,能降低总耗时。安全前提是每个并发任务相互独立、结果可合并、失败可隔离,不能把有顺序依赖或会产生副作用的操作盲目并行。

• +读操作通常更容易并行,写操作要考虑锁、幂等和事务
• +并发结果合并要处理冲突、超时和部分失败
• +多路模型调用会快速增加成本,需要预算控制和取消机制

不能让模型直接拥有无限 Shell 权限。要用沙箱、命令白名单、目录隔离、超时、资源限制和人工确认来控制风险,并把模型生成的命令当作待审核建议而不是可信指令。

• +危险命令如删除、网络上传、修改权限、读取密钥要默认禁止或人工批准
• +执行环境要隔离项目、凭据和用户数据,不要共用开发者本机权限
• +所有命令、输出和审批记录都要留审计日志,便于追责和复盘

这属于间接 Prompt Injection,文档内容必须被视为数据,不能被视为系统指令。处理方式是给外部内容加边界,明确模型只提取事实,并在执行动作前由系统规则和权限层做校验。

• +RAG、网页、邮件、工具返回值都可能携带恶意指令
• +不要把检索内容和系统规则混在同一段无边界文本里
• +涉及发邮件、转账、删文件等动作时必须二次确认或走审批

高风险、不可逆、涉及钱、权限、隐私、法律责任或对外发送的操作都应该有人在回路中确认。模型可以准备建议和草稿,但最终执行权要由用户或授权系统掌握。

• +典型例子包括付款、退款、删库、发正式邮件、改生产配置、提交法律文件
• +人工确认要展示模型依据和将要执行的具体动作,不能只给一个模糊按钮
• +低风险操作可以自动化,但也要有回滚和审计

Jailbreak 通常是用户直接诱导模型突破安全策略,Prompt Injection 则常通过外部内容或用户输入污染指令层级。两者都在试图改变模型行为边界,但攻击入口和防护重点不同。

• +Jailbreak 更像对模型安全策略的直接对抗,Prompt Injection 更像应用层上下文污染
• +防护不能只靠模型拒答,还要靠权限、隔离和工具调用约束
• +评估时要覆盖直接恶意请求、隐藏指令、跨文档注入和多轮诱导

两端都要放。输入端用于识别恶意请求、敏感信息和越权意图;输出端用于检查泄密、违规内容、格式错误和危险操作建议,中间工具调用层还要做权限和参数校验。

• +输入拦截可以降低风险,但不能保证模型内部不会被上下文带偏
• +输出校验适合结构化结果、敏感词、PII 和策略合规检查
• +工具层 guardrail 最关键,因为它控制真实世界副作用

PII 要最小化收集、最小化暴露、按权限访问,并尽量在进入模型前脱敏。系统要明确哪些信息能存、能传给模型、能进入日志,以及用户如何删除或导出这些数据。

• +日志和向量库是常见泄漏点,不要把原始身份证、手机号、密钥长期保存
• +多租户检索必须做权限过滤,避免把 A 用户信息召回给 B 用户
• +合规场景要考虑数据地域、保留周期、审计和供应商数据处理条款

Computer Use 是让 Agent 像人一样观察屏幕、点击、输入和操作应用。普通工具调用通常是结构化 API,Computer Use 面对的是视觉界面和不稳定 UI,更通用但也更慢、更难验证、更需要安全边界。

• +适合没有 API、只能通过 GUI 完成的任务,例如旧系统录入
• +要限制可操作应用、可访问文件和敏感区域,避免误点高风险操作
• +视觉识别、坐标点击和界面变化都会带来不确定性,必须有回退和确认

传统爬虫主要按规则抓页面和解析数据,Browser Agent 则能在浏览器里理解页面、点击、填写表单、处理登录流程并根据目标调整步骤。它更像自动化操作员,而不是只做数据采集的脚本。

• +Browser Agent 能处理动态页面和复杂交互,但成本和不确定性更高
• +涉及登录、下单、提交表单时要有人确认和权限隔离
• +能用 API 或稳定爬虫解决的问题,不一定需要 Browser Agent

Coding Agent 通常是读需求、检索代码、制定修改点、编辑文件、运行测试、根据错误修复、最后总结变更。它的关键不是一次写完代码,而是能在代码库反馈中迭代,把失败的测试和构建错误当作下一步输入。

• +优秀 Coding Agent 要会遵守仓库风格,而不是生成孤立代码片段
• +必须有版本控制和测试验证,否则很难信任它的修改
• +权限边界很重要,例如不能随便删除文件、泄露密钥或执行危险命令

A2A 关注不同 Agent 之间如何发现能力、交换任务、传递状态和返回结果。它要解决的是跨系统协作问题,让一个 Agent 能把任务交给另一个更专业的 Agent,而不是所有能力都塞进同一个进程。

• +核心难点是身份、权限、任务协议、状态格式和错误处理
• +A2A 不是简单聊天,更需要结构化任务、能力描述和可审计链路
• +实际落地时要防止权限外溢,不能因为另一个 Agent 请求就默认执行

多模态 Agent 能同时处理文本、图片、音频、视频或屏幕状态,适合质检、客服、教育、医疗辅助、设计审阅和机器人控制等场景。它的价值是把"看见"和"行动"连起来,不再只处理文字指令。

• +视觉输入要考虑分辨率、遮挡、OCR 错误和隐私脱敏
• +多模态输出如果会驱动物理或生产动作,必须有更强安全校验
• +很多场景需要把视觉理解转成结构化状态,再交给后续工具执行

最该警惕的是把演示能力误认为生产可靠性。前沿 Agent 往往能完成令人惊艳的单次任务,但上线要看稳定性、权限、安全、成本、延迟、可观测性和失败恢复。

• +先选低风险、可回滚、有明确成功标准的任务落地
• +演示视频不等于评估结果,要用真实数据和失败样本验证
• +越接近真实世界操作,越需要沙箱、审批和审计