参考答案： 我有四年开发经验，求职方向是 Agent 应用和 AI 全栈。简历中的两个重点项目分别是运维知识 RAG 和运维任务 Agent，我担任核心开发，关注知识处理、检索编排、工具调用，以及服务和业务交互的衔接。我的优势是能把 AI 能力接入具体业务流程，从需求拆解推进到应用交付。接下来我想继续深入 Agent 的执行可靠性和效果评估。

参考答案： 四年指整体软件开发经验，不全是 AI 开发。早期主要做业务系统与应用工程，后续参与知识检索和智能体开发。AI 经历按具体项目时间说明；此前的服务集成、交互和工程化经验帮助我完成 AI 应用交付。

参考答案： API 调用只解决模型输入输出。我更关注业务数据如何接入、工具参数和权限如何校验、执行失败后怎样恢复，以及结果如何验证。比如工单创建超时，系统需要核查是否已成功，不能让模型随意重试。差异要用一个实际模块和失败案例证明。

参考答案（示例案例）： 我在两个项目中都是核心开发。RAG 项目主要负责文档处理、混合检索和检索编排，智能体项目主要负责工具适配、任务状态与流式接口。业务同事协助确认故障分类和检修规则，其他开发同事负责原有告警、设备和工单系统。我承担两边的数据契约与联调。一个具体贡献是把工单创建的超时处理从直接重试改为先核查结果，再决定是否重试，避免重复建单。

参考答案： 从职责看，RAG 提供知识查找与证据，任务 Agent 负责根据目标选择动作并推进流程。Agent 可以调用检索服务，但是否在实际项目中复用，要按真实架构回答。两者可独立演进：知识接入和索引更新不必与任务审批、工具执行一起发布。

参考答案（示例案例）： 早期 Agent 主要查询告警、设备台账和历史工单，排查规则来自业务整理的结构化故障分类与处理步骤，还没有接入后来的独立 RAG 平台。随着运维手册和历史材料增加，原来的查询方式难以覆盖跨文档问题，才单独建设文档处理、混合检索与精排链路。两段经历分别对应任务流程建设和知识能力建设，不能把后建成的平台说成早期已有依赖。

参考答案： 应按项目锁文件、提交记录和部署版本说明，区分项目起始时间与技术引入时间。如果在后期试验或重构中采用，应明确具体阶段。我不会把现在文档里的接口，当作当时版本已经具备的能力。

参考答案（示例案例）： 我的技术经理职责主要是方案设计、任务拆分、接口协调和关键代码开发，并不是脱离实现的纯管理岗位。我仍然承担检索链路、工具适配和复杂问题排查。现在希望岗位继续以技术交付为主，把精力集中到 Agent 的状态管理、执行可靠性和效果评估上，所以 Agent 或 AI 全栈开发岗位与我的发展方向一致。

参考答案（示例案例）： 这是面向内部运维人员的业务应用，交付重点是把原来跨系统查询、查手册和整理方案的操作串成一个任务流程。知识侧接入规模约 3000 份文档、4.2 万个 Chunk。验收时覆盖设备明确、信息缺失、无相关知识和工具超时等场景，检查是否找到依据、是否按规则停止以及是否正确处理工单状态。我没有把文档量当成并发能力，也没有将未经统计的使用感受换算成收益百分比。

参考答案（示例案例）： 一次联调中，用户只确认了一次检修方案，工单系统却出现了两张内容相同的工单。我先对照前端事件和服务端 Trace，排除了重复点击以及模型在同一轮主动发起两次调用。最终发现第一次创建已经在下游成功，但响应超过了本地超时限制，通用重试逻辑又发出了一次请求。

我的调整是把查询重试与写入重试分开。创建操作先保存稳定的业务请求标识和参数摘要，超时后标记为结果待确认，通过关联号查询下游结果；确认成功就补记工单 ID，支持幂等的接口才使用同一标识重试。对于无法确认结果的情况，保留人工核查入口。

验证时在同一组任务中注入“提交前失败”“下游成功后响应丢失”和“本地记录前进程中断”，检查外部工单数量和本地最终状态，而不是只看接口有没有报错。这个方案的边界是：如果下游既不支持幂等，也无法查询关联结果，就不能承诺自动处理绝不重复。之后把这些故障注入场景加入了回归检查。

参考答案： 在这里，Agent 根据目标和工具返回结果选择下一步动作，执行后继续观察，直到完成、失败或交给人工。普通聊天机器人可能只生成回复。判断是否是 Agent，主要看模型是否参与运行时决策，而不是页面是否支持聊天。

参考答案： Workflow 的主要路径由程序预先定义；Agent 可以在允许范围内动态选工具和步骤；RAG 是检索外部信息辅助生成的方法，可以作为工作流或 Agent 的一个环节。真实业务常把三者组合：固定审批边界，动态选择查询动作，用 RAG 补充知识。

参考答案： 用户描述通常不完整，排查路径又取决于查到的证据。多设备同时离线与单设备异常需要不同查询。如果路径完全固定，用工作流更简单；Agent 的价值是减少人为拼接查询步骤，但权限、写入和终止条件仍由程序控制。

参考答案： ReAct 可以理解为推理判断、执行动作和观察结果交替进行。工程上保存工具选择、参数、结果和简短依据即可，不需要依赖或展示模型内部逐字思维链。用户应看到可验证的依据和处理进度。

参考答案： 构造上下文并调用模型；有工具请求就做 schema、权限和预算校验，执行后把结果关联原 tool call 返回模型；没有工具请求时检查是否满足完成条件。循环之外还要有总超时、取消、调用次数限制和状态记录。

参考答案： 可以把 LangChain 看作模型、工具与应用集成的抽象，LangGraph 更侧重有状态执行与编排。当前框架能力有交集，面试时应说清项目版本及实际使用接口，而不是机械地说“一个只能链式，一个只能图式”。RAG 中关键是显式表达检索、判断和重试分支。

参考答案： 少量稳定分支可以直接写。状态跨多步保存、存在回路、人工介入和恢复需求时，图式表达更方便管理节点与迁移。但框架不能替代业务状态设计，也不会自动解决外部副作用的幂等。

参考答案： 可以按不同服务的语言生态和编排需求选择。Python 检索服务用显式图组织步骤，TypeScript 业务服务用 Agent 运行时接工具和事件流。这只是合理选型解释，实际采用原因要对应代码。还应明确简历中的 Pi 指 agent-core 还是 coding-agent SDK；官方将底层有状态 Agent、工具执行和事件流与较高层 SDK 分开提供。Pi Agent Core ↗、Pi SDK ↗

参考答案： 应先报实际包名和版本，再讲工具定义、模型配置、事件订阅与停止执行的真实代码。当前 Agent Core 文档提供 Agent 状态、事件订阅和上下文转换等能力，但不能据此推定历史项目 API。最好的准备是拿自己的锁文件与一个最小运行实例复述数据流。Pi Agent Core 文档 ↗

参考答案： 单 Agent 配合明确工具通常更容易调试。只有子任务能独立处理、专业上下文差异明显或并行收益充分时，才考虑多 Agent。代价包括额外模型调用、通信信息损失、共享状态冲突及评估复杂度。代理数量本身不能证明系统更先进。

参考答案： 我会固定一批运维问题，分别覆盖故障编号查询、模糊描述、混合意图、证据不足和工具失败，再比较候选模型的工具选择、参数正确性、依据使用、延迟与成本。比如一个模型回答更流畅，但会猜测缺失的设备 ID，就不适合直接承担工具调度。简单分类可使用较小模型，复杂诊断再升级，但每条路由都要验证，而不是仅根据通用榜单选型。

参考答案： 较低温度可能减少输出变化，但不保证确定性，更不保证正确。模型版本、推理实现和上下文变化都可能影响结果。业务可靠性主要靠输入约束、程序校验、状态控制和重复评估，而不是一个采样参数。

参考答案： 应用把工具说明和参数结构交给模型，模型返回工具名与参数，真正执行由应用负责。即使 JSON 符合 schema，也可能选错设备、时间范围或无权限对象，因此还需要业务校验、身份授权和必要的人工确认。

参考答案： 设置步数、总时间、token 和工具预算；记录标准化工具名与参数，识别无新证据的重复调用。可重试错误只允许有限重试，信息不足转澄清。终止时返回已确认事实、未解决问题及停止原因。

参考答案： 分开写角色目标、允许动作、工具约束、输出格式和异常处理，再提供少量有代表性的例子。模板版本化，变量通过明确字段注入；每次改动跑回归样本。权限等硬规则不能只写在 Prompt 中。

参考答案： 首先确定用户权限、设备和问题范围；根据问题执行 BM25 与向量检索，合并去重后精排；选择满足上下文预算的证据，再生成带来源的答案。证据不足时有限改写或澄清，不能靠生成补齐不存在的事实。离线还有解析、分块、向量化与索引更新链路。

参考答案： 故障编号和型号更依赖精确词项匹配，自然语言描述更需要语义匹配。两路互补，但收益必须用业务问题集验证。设备、租户和文档权限等确定条件适合做结构化过滤，而不是交给语义相似度猜。

参考答案： 它结合查询词在文档中的出现频率、该词在语料中的稀有程度和文档长度归一化来排序。词频收益会饱和，避免重复堆词无限加分。中文分词和故障代码字段建模很重要；精确编号可用 keyword 字段，正文采用适合的文本分析器。

参考答案： BM25 与向量分数的尺度不同，不能不加处理直接相加。候选方案是 RRF，用排名倒数加权：score(d) = Σ 1 / (k + rank_i(d))，统一 Chunk ID 去重后再精排。也可以校准分数后做加权融合；最终看验证集。RRF 是设计选项，简历没有确认实际融合算法。Elastic RRF 文档 ↗

参考答案： 这个规模不自动要求两套引擎。若已有 ES 基础设施、Milvus 服务或独立性能需求，分工可能合理；否则统一检索引擎可能更省维护成本。需要权衡检索质量、索引一致性、部署和团队经验，不能仅说“ES 做关键词、Milvus 做向量，所以必须分开”。

参考答案： Embedding 把查询和文档分别编码，文档向量可预计算，适合大规模候选召回。Cross-encoder 类 Reranker 联合处理查询和候选文本，通常更精细但逐对计算成本更高，所以放在候选集之后。具体性能要实测。BGE Reranker 官方文档 ↗

参考答案： 先按标题、段落和表格等结构划分，再结合模型 token 上限限制长度。可以测试几组大小，例如 300、600、900 token，观察召回、答案完整性和成本；这些是实验候选值，不是项目参数。Overlap 用来保留边界信息，但过大会产生大量重复候选。

参考答案： 太小会丢失条件和结论的联系，太大容易把无关内容带入模型。可以采用小块召回、按需补充父段落或邻近片段的方式，既保持定位精度，也提供上下文。扩展后仍要按权限、去重和 token 预算截取。

参考答案： 保留页码、表头、列对应关系和单元格位置。根据续表特征和列结构判断能否合并，不能仅因相邻页都有表格就拼接。转文本时重复必要表头，让每行数据保留含义；低质量表格保留原页定位，便于复核。

参考答案： 区分电子文本与扫描页，保存原文和转换结果。处理重复页眉、断行、异常空白等规则性噪声；型号、编号和数值纠错必须谨慎，例如 O/0 不宜全局替换。对低质量页重新识别或人工核查，记录清洗版本以便复现。

参考答案： 建议有 document_id、chunk_id、文档版本、内容 hash、标题路径、页码或定位信息、来源、更新时间、租户和访问范围。Embedding 模型与分块策略版本也应可追踪。这样才能处理更新、权限过滤、引用和问题复现。

参考答案： 用稳定文档 ID 和内容 hash 识别变化，变化后生成新版本 Chunk 并更新两路索引。删除要覆盖向量、文本、缓存和可见版本。整篇重切时 Chunk ID 可能变化，不能只追加不清理旧数据；接入任务要可重试且可追踪。

参考答案： 把文档版本和接入任务状态作为事实来源，两路分别幂等写入、记录进度并补偿重试。可在两路准备好后切换可见版本；查询端按共同版本过滤并监控不一致。不要宣称两个独立存储天然具备原子事务。

参考答案： 新旧向量空间通常不可混用，需要对文档重新编码并构建新索引。查询端必须使用匹配的模型和预处理方式；比较效果、延迟和成本后切换，保留回退能力。模型维度相同也不代表向量兼容。

参考答案： 根据规模、内存、召回率与延迟实测。FLAT 可作为精确搜索基线；HNSW 以图结构做近似搜索，通常需要更多内存；IVF 类方法把向量分区，查询探索部分分区。4.2 万条应先测简单方案，再决定是否需要复杂索引。Milvus 索引说明 ↗

参考答案： 分别控制两路召回数量、融合后的候选数与最终证据数量。可以实验每路 30 条、融合后精排 40 条、选 5 条等配置，但不能当作项目实际值。关注关键证据是否进入候选集、精排耗时与上下文冗余；最终还应按 token 预算和证据覆盖度选择。

参考答案： 同时检查实体、时间和型号是否匹配，问题要求的关键字段是否有依据，以及证据是否互相矛盾。检索分数只能辅助判断，不能直接解释为答案正确概率。对“根因是什么”这类问题，还要区分相关性与因果证据。

参考答案： 改写可能丢失否定、时间范围或故障编号，拆解可能引入用户未问的内容。因此保留原始问题和固定实体约束，限制子问题数量，并比较改写前后证据是否增加。没有新证据时停止，不连续改写到模型产生一个看似完整的答案。

参考答案： 给每条检索证据分配允许引用的 ID，让模型输出结论与证据 ID，程序验证 ID 确实来自本次可见结果，再检查引用是否支持结论。引用存在不等于论断成立；证据不足时允许回答不知道，或列出需要人工核查的事项。

参考答案： 从已认证身份获得租户和权限范围，在召回阶段应用过滤，不能只在最终页面隐藏。缓存、来源链接、邻接片段扩展也必须遵守相同规则。模型生成的 tenant_id 或角色字段不作为授权依据，权限变更后需要处理缓存失效。

参考答案： 可以缓存查询向量或检索结果；答案缓存还需考虑 Prompt、模型和上下文。Key 应包含规范化问题、知识版本、检索配置及权限范围；TTL 根据更新频率确定。涉及当前告警的结果要注意时效，不能让静态知识缓存掩盖实时数据变化。

参考答案： 热点失效用单次回源合并或受控锁，避免同时计算；大量 Key 同时过期可加过期抖动；非法请求先校验，空结果只在合适条件下短暂缓存。锁要有归属校验和有效期，缓存不能成为唯一业务事实来源。

参考答案： 分开评估召回和生成。检索看 Recall@K、排序质量及关键证据覆盖；答案看事实正确性、依据支持、引用准确和拒答表现；系统看延迟、成本与错误率。构建正常、跨文档、无答案、过期资料和权限场景，避免只测试演示问题。

参考答案： Recall@K 是前 K 条命中的相关项占全部标注相关项的比例；MRR 对每个问题取第一个相关结果排名的倒数再平均；nDCG 衡量带分级相关性的排序质量并做归一化。要先明确相关单位是文档、Chunk 还是证据，否则指标不可比较。

参考答案： 从真实脱敏问题、历史工单和文档采样，人工标关键证据与不可回答条件，再逐步增加失败样本。LLM 可辅助生成和评分，但需用人工样本校准，检查位置偏差和错误偏好。训练式调参使用的样本与最终保留集应分开。

参考答案： 在相同语料和问题集下比较 BM25、向量、混合及混合加精排，控制其他变量，分别看不同题型的质量和延迟。若精排后变差，检查候选截断、模型适配与输入格式。没有做消融实验时，只能讲设计动机，不能声称量化提升。

参考答案： 频繁更新且需要引用的知识适合检索；稳定的输出风格或任务行为可以考虑微调；少量完整资料也可直接放长上下文。它们可以组合，但都需要评估。微调不适合充当实时知识数据库，长上下文也不保证模型找到关键证据。

参考答案： Function Calling 解决模型如何提出工具调用，MCP 规范应用与外部能力服务之间的发现和通信。应用可以把 MCP 工具转换为模型的工具定义，再把模型请求转成 MCP 调用。MCP 本身不等于 Agent 调度器，也不会自动完成权限与业务审批。MCP Tools 规范 ↗

参考答案： Host 是承载用户交互与模型调用的应用；Client 负责与某个 Server 的协议连接；Server 暴露工具、资源等能力。运维系统中，业务服务可以作为 Host，通过 Client 调用告警工具 Server。实际架构也可以直接用内部函数，不必把所有调用都包装成 MCP。

参考答案： 工具名称体现业务意图，描述说明何时用、限制和副作用，参数尽量少且含义明确。例如查询告警要求设备 ID、时间范围和分页限制；返回稳定业务字段、来源和错误类型，避免直接塞入巨大原始响应。

参考答案： 返回稳定错误码、是否适合重试、缺失参数及部分结果，例如 OBJECT_NOT_FOUND、PERMISSION_DENIED、RATE_LIMITED、OUTCOME_UNKNOWN。不要只写“失败了”。协议层错误与业务执行错误要区分，MCP 工具执行错误可以通过 isError 表达。MCP Tools 规范 ↗

参考答案： 先按当前任务和权限缩小可见工具集，合并职责重复的接口，改进名称、参数说明与正反例。通过混淆样本观察模型把哪些工具弄混。可以加入工具检索或阶段路由，但路由错误也要有回退，不是拆得越多越好。

参考答案： 先做结构校验，再做业务校验。缺少设备时澄清，不凭空补 ID；日期超范围返回可修正错误；权限失败由服务端拒绝。只对安全且明确的格式问题自动规范化，不能悄悄把用户目标改成另一个对象。

参考答案： 协议鉴权证明客户端可以访问 MCP 服务，业务层仍要判断该用户能否操作具体设备和工单。HTTP 授权场景要处理 token 的受众、scope 和有效期；访问下游 API 也应使用正确的凭据边界，不盲目透传上游 token。MCP Authorization ↗

参考答案： 文档和工具返回是业务数据，不是新的控制指令。通过上下文分区提示模型忽略其中的操作要求，同时让权限、工具白名单和审批由服务端执行。还要测试间接提示注入、恶意链接和数据外传请求，仅靠一句 Prompt 不足以防护。

参考答案： 临时网络问题、部分服务端错误和限流可在预算内退避重试；参数错误、权限失败应修正或终止。写入超时属于结果未知，先确认是否已经成功；是否幂等比 HTTP 状态码更重要。退避加入抖动并遵守服务端的重试提示。

参考答案： 由服务端为一次业务意图生成并持久化，绑定用户或租户、操作类型与审批后的方案版本，所有重试复用。数据库加唯一约束并保存请求摘要、状态和结果；同 Key 不同参数应拒绝，不能每次重试重新生成 UUID。

参考答案： 将操作标为结果待确认，通过幂等键或业务关联号向下游查询；查到成功就补记工单 ID。下游支持幂等时可复用同 Key 重试；不支持幂等且不能确认结果时，应转人工核查，不能保证自动重试绝不重复。

参考答案： 不能单独保证。锁可能过期、进程可能停顿，也可能出现远端成功而本地未记录。锁可以减少并发执行，但可靠性还需要持久化幂等记录、唯一约束、下游幂等和结果核查。进程恢复后也要能找到原操作。

参考答案： 保存待审批的结构化方案、版本和状态，用户明确确认后记录批准人、时间及范围。执行前校验当前方案与批准版本一致、权限仍有效，并原子领取执行权。审批期间不应一直占用模型请求或数据库事务。

参考答案： 不能。设备、操作和关键参数属于审批内容，变更后生成新版本并使旧批准失效。执行入口按方案版本和摘要检查，避免只维护一个全局 approved=true。摘要生成要统一字段序列化，排除无关展示字段。

参考答案： 使用状态条件更新或乐观锁，只有一个请求把相同版本从待审批推进到已批准或执行中，其他请求返回已有状态。后续业务执行仍使用同一幂等键。前端禁用按钮只能改善体验，不能承担并发一致性。

参考答案： 根据业务设置批准有效期；执行前复核设备状态、告警是否仍有效、权限和方案版本。发生实质变化时要求重新确认。审批和执行之间存在时间差，不能把曾经可执行当作永远可执行。

参考答案： 无依赖且只读的查询可以在限流范围内并行，比如设备信息与历史工单查询；依赖上一步结果的步骤应串行。同一设备的冲突写入不应并行。还要处理局部失败、取消和总预算，不能无上限 Promise.all。

参考答案： 不能仅凭取消请求作保证。停止可以终止后续模型调用和未发出的动作，但已经发送到外部系统的写入可能成功。需要查询执行结果并明确展示已完成、已取消或结果待确认；撤销应是单独的业务操作。

参考答案： 保存 task_id、用户与权限范围、原始目标、已确认实体、当前阶段、证据引用、工具操作记录、待审批方案版本、预算与错误状态。重要业务状态使用结构化字段，聊天文本是补充，不应靠模型从全部消息里重新推断是否已建单。

参考答案： Checkpoint 保存图执行状态，便于对话延续与恢复；业务数据库保存工单操作、审批、幂等结果等业务事实，两者职责不同。恢复执行时某些步骤可能再次运行，所以外部副作用仍要独立保护。LangGraph Persistence ↗

参考答案： 使用持久化 checkpointer 保存状态，保持正确的 thread_id，在中断点等待外部输入，再通过恢复命令继续。节点恢复涉及重新执行边界，应避免在中断前放没有幂等保护的写入。内存保存器不适合要求进程重启后恢复的场景。LangGraph Interrupts ↗

参考答案： 保留近期完整对话和当前任务关键字段，对旧历史形成摘要；完整原始记录另行保存以便追溯。裁剪要保留工具请求与结果的合法配对关系。摘要用于压缩背景，设备 ID、审批状态和操作结果必须由结构化状态提供。

参考答案： 关键字段不通过自由摘要维护，而是从已确认状态注入。摘要中出现冲突时，以结构化事实与来源记录核查；必要时重建摘要或请求用户确认。评估要包含否定、数字、时间和目标变更，不能只看摘要是否通顺。

参考答案： 短期记忆保存当前会话与任务进展；长期记忆保存经过确认、允许跨会话使用的偏好或事实；知识库存储业务资料。不是所有聊天都适合长期保存，记忆需要来源、有效期、修改和删除机制。

参考答案： 从持久化任务状态找出可恢复任务，按租约或状态条件领取，检查最后一次工具操作是否完成，再继续下一步。结果未知的写入先核查，等待审批的任务继续等待。不要无条件从用户第一句话重新执行所有步骤。

参考答案： 用数据库条件更新、版本号或租约领取任务，并阻止旧执行者继续提交状态。即使调度层避免了多数重复，工具层仍需幂等。消息队列至少一次投递时尤其不能假定任务只会消费一次。

参考答案： 区分补充信息、取消和目标变更。将输入按任务版本串行合并，在安全边界重新规划；目标变更使旧方案失效。已发出的外部动作需要先核查，不能覆盖历史后假装它从未发生。

参考答案： Prompt 关注指令表达；上下文工程还包括本轮带哪些历史、证据、工具定义和状态，如何裁剪、排序、更新和控制预算。长任务的主要问题常是无关信息堆积或关键状态丢失，并非少写了一句提示。

参考答案： 看最终业务状态是否满足目标、工具参数与权限是否正确、是否误写入，还要记录成本、耗时和人工介入。允许不同合理执行路径，不要求逐步复刻标准轨迹。回答说建单成功，但外部不存在工单，应判为失败。Anthropic Agent 评估实践 ↗

参考答案： 由真实脱敏任务、历史失败与人为构造的边界场景组成，包含目标、初始系统状态、可用工具、预期结果和禁止动作。写入使用隔离环境，运行后恢复状态。对高波动任务重复执行，观察稳定性，不只保留最好的一次。

参考答案： Mock 用于稳定复现超时、错误和特殊返回；集成测试验证接口契约、权限、数据格式与实际副作用。不能只测 Mock 后宣称整个系统可用。另用少量在线模型回归检查行为变化，并控制成本和随机性。

参考答案： Trace 关联一次跨组件请求，Span 表示其中一个步骤，Metric 汇总延迟与错误等数值，Log 记录具体事件。运维 Agent 可以为任务、模型请求和工具执行建立关联，跨服务传播上下文，帮助区分慢在模型、检索还是外部接口。OpenTelemetry Signals ↗

参考答案： task_id、操作 ID、模型与 Prompt 版本、工具名、状态、耗时、重试次数和 token 用量；敏感参数与正文按需脱敏，避免完整记录密钥和个人数据。高基数 task_id 适合 Trace/Log，不适合作为常规指标标签。

参考答案： 不等于。查看历史 Trace 是观察过去；重放需要保存输入、工具结果、配置与模型版本，并明确是否真实执行副作用。调试可使用录制的工具结果离线重跑模型判断，不能对生产建单操作直接再次执行。

参考答案： 首字可能只是“正在处理”，真正有用的结论或工具结果仍很晚。需要分别测首事件、首个有效信息、完整结果和任务完成耗时，并看 p50/p95。优化关键路径与不必要调用，比提前发一段空泛文字更有效。

参考答案： 先按 Trace 找主要消耗，再减少重复检索和无效工具循环，压缩冗余上下文、缓存稳定结果、对独立只读查询并行，并按任务难度路由模型。每项优化都要回归质量；重试和升级模型的额外成本也计入单任务成本。

参考答案： 根据租户和全局预算限流，短时失败退避重试，持续失败熔断或降级。备用模型要经过相同工具协议与质量验证；如果无法保证关键能力，返回当前进度或转人工。不能因降级而绕过审批。

参考答案： 固定版本并跑保留集，先小范围灰度，监控成功率、误操作、延迟和成本；保留快速回退能力。正在运行的任务应记录原配置版本，避免中途混用新旧逻辑。影子流量只能观察或模拟，不能重复执行生产写入。

参考答案： 可以让 TypeScript 承担业务 API、工具适配与流式交互，让 Python 承担文档处理和检索生态相关工作。前提是这确实对应项目实现。跨语言服务会增加部署、契约与排错成本，小规模团队也可以统一语言，不为展示全栈而拆服务。

参考答案： 选型应结合团队已有技术、路由和中间件需求、输入验证、异步依赖与部署环境说明。Hono 便于 TypeScript 服务组织，FastAPI 与 Python 数据处理配合方便。不能只背“轻量、高性能”；关键要讲使用了哪些中间件与错误处理方式。

参考答案： JavaScript 主执行线程通过事件循环协调非阻塞 I/O，部分底层操作由系统或线程池处理。并发不等于 JS 计算并行。大段同步解析或计算会阻塞其他请求，可用 Worker、独立进程或后台任务处理。

参考答案： 不会。它主要让等待异步操作的控制流更清晰；CPU 工作仍要实际执行。Python 中调用同步 OCR 或本地模型不能仅加 async def 就避免阻塞，应结合进程、线程支持情况或独立推理服务安排执行。Python asyncio 文档 ↗

参考答案： 区分模型批处理与请求并发：按 token 或长度组 batch，提高推理利用率；通过信号量或队列限制并发，受显存、接口配额和下游写入速度约束。保存文档任务进度，只重试失败项，避免全量重新编码。

参考答案： 对外部调用设置超时，清理资源放在 finally 中，不随意吞掉取消异常。TaskGroup 与 gather 的失败传播行为不同，应按是否允许局部成功选择。即使本地协程被取消，外部写入仍可能成功，需要业务层核查。Python Tasks 文档 ↗

参考答案： TypeScript 类型主要在编译期发挥作用，外部输入仍需运行时校验。Pydantic 可做结构和字段验证，但权限、设备是否存在、业务状态是否允许操作，要查询业务事实后判断。结构正确只是第一层。

参考答案： 请求可能超时或中断，进程重启会丢进度。可以先创建任务返回 ID，后台执行并记录阶段、失败项和进度，用户通过查询或事件流查看。队列重投时要幂等，不能把“后台执行”等同于“可靠执行”。

参考答案： 模型响应以服务端向客户端持续推送为主，SSE 比较直接；频繁双向低延迟消息可以考虑 WebSocket。用户操作可通过普通 HTTP 发给服务端。选择还取决于代理、认证和部署环境，不是 SSE 永远更优。MDN SSE ↗

参考答案： 原生 EventSource 不方便设置任意 Authorization 头，可以使用合适的 Cookie 认证或 fetch 流。事件带单调序号，重连带游标，服务端保留可补发记录；超过保留范围返回状态快照。客户端去重，不能因重连再次创建任务。MDN SSE ↗

参考答案： 设计带 type、task_id、sequence 和 payload 的事件，例如 text_delta、tool_started、tool_finished、approval_required、task_completed。文字增量用于显示，结构化状态驱动卡片与按钮；不能从一段自然语言里猜工单是否已经创建。

参考答案： 增量阶段显示文字或明确的进行中状态，完整结构接收并验证后再更新关键业务卡片。对部分 JSON 的容错解析不能触发写入。卡片操作绑定服务端实体 ID 和版本，而不是直接相信模型输出对象。

参考答案： 按任务 ID 和序号归并事件，忽略旧版本或重复事件，缺口用补发或快照恢复。Markdown/HTML 渲染做清理和 URL 校验，不能直接插入模型原始 HTML；工具结果链接也应验证来源和可访问性。

参考答案： 分别检查模型是否真的流式返回、应用是否及时 flush、反向代理或压缩是否缓冲，以及负载均衡超时。发送心跳保持连接，控制慢客户端缓冲；即使连接断开，业务任务状态仍由服务端持久化管理。

参考答案： 可以分成任务、方案版本、审批记录、工具操作记录四类实体，分别保存状态与引用；操作记录对租户和幂等键建立唯一约束。外部工单 ID 与本地任务 ID 分开，审批关联明确版本。实际数据库类型与字段需按项目说明。

参考答案： 普通数据库事务不能原子覆盖独立 HTTP 服务。避免在长事务里等待模型或外部接口，可以先持久化操作意图，再由执行器调用并记录结果，失败后核查或补偿。Outbox 解决本地状态与待发送事件的一致性，不能自动保证远端只执行一次。

参考答案： 看真实查询条件、执行计划、扫描行数和锁等待，再设计复合索引；例如租户、设备和时间范围的组合。大偏移分页可考虑基于稳定排序键的游标方式。不能为所有字段加索引，写入与存储成本也需权衡。

参考答案（设计示例）： 我会把 API 与后台任务处理器分开部署，配置和密钥外置。就绪检查决定能否接新请求，关停时先停止领取任务，再保存执行状态。发布前跑接口与典型任务回归，记录应用、模型和 Prompt 版本；小流量验证后切换。发生异常时回退应用，但不盲目撤销已成功的工单，数据变更保持新旧版本兼容。

参考答案： 分开测应用和外部模型限制：用可控 Mock 压服务调度、数据库和 SSE，再用真实模型测代表性并发、配额和费用。观察完成吞吐、p95 延迟、连接数、队列长度与失败率；长任务并发数不能简单等同于每秒请求数。

参考答案： 身份进入服务后贯穿数据库查询、检索、缓存和工具授权；按租户限制并行任务、token 和工具调用，防止一个租户耗尽共享资源。指标与日志同样控制可见范围，不能只在 URL 上加 tenant_id。

参考答案： 它体现模块划分、接口契约和工程交付能力，可以支撑 Agent 的任务界面与业务接入。我会用两三句话说明价值，把主要时间留给 AI 项目，不把组件数量作为 Agent 能力证明。

参考答案： admin 承载业务页面，app-core 统一启动与请求运行时，components 放复用交互，shared 放通用能力。重点是依赖方向清楚，避免 shared 反向引用业务。拆包需要解决真实复用或隔离问题，不是目录越多架构越好。

参考答案： 便于跨包一致修改和复用类型，也会带来依赖边界、构建影响范围和版本管理问题。需要明确各包出口、依赖方向与检查范围。pnpm workspace 是组织工具，架构边界仍由代码和规范保证。

参考答案： 读取并校验规范，解析 schema 与引用，生成确定性的类型文件；对枚举、可空、联合类型和命名冲突做好处理。开发时避免无变化重复生成或触发循环热更新，CI 检查产物是否同步。类型生成不能替代运行时验证。

参考答案： 将路由注册、状态管理和接口约定写成可复用操作规则，减少 AI 生成代码偏离工程习惯。规则最好配真实文件位置与检查方法，保持短而准确；效果通过代码评审和测试确认，不能认为写了规则就保证生成正确。

参考答案： 先明确验收条件和修改范围，检查关键实现，再让工具生成局部改动；重点审阅权限、异步状态和数据写入，跑相关测试并看完整 diff。对无法解释的实现先查明，不直接提交。模型输出与人工代码遵循同样审查标准。

参考答案（示例案例）： 我会把“告警诊断并生成工单”拆成三个可验收阶段：先查到正确设备与告警，再生成有依据的检修建议，最后加入人工确认和建单。优先联调风险最大的工单接口，明确超时后能否查询结果。并行开发前约定工具输入、错误码和事件格式，每个阶段都用完整任务验收；这样即使某个外部接口延期，也能清楚说明当前已经交付的能力和受阻部分。

参考答案（示例案例）： 方案讨论时，有同事希望把排查拆成多个 Agent，我担心上下文传递和排错成本。我们先约定目标是正确识别设备、找到依据并生成可审核方案，再用同一组任务比较固定流程加单 Agent 与多 Agent 方案。第一版先采用前者，把工具接口保持独立；如果后续出现可以独立并行的任务，再拆分执行单元。这样把争论落到可验收结果上，也避免第一版承担不必要的协调复杂度。

参考答案（示例案例）： 我希望下一阶段把主要精力投入 Agent 应用和 AI 全栈工程，持续解决工具执行、状态恢复以及效果评估这些问题。过去的业务系统和工程化经验让我能完成应用交付，现在更希望在有明确 AI 业务场景的团队中继续深入。我的不足是模型训练与大规模推理优化经验相对有限，因此当前定位是应用工程；技术准备重点放在检索评估、工具调用边界和任务可靠性，而不是把自己包装成算法研究人员。

参考答案： 可以询问当前 Agent 的具体用户与任务、上线验收指标、最主要失败类型，以及岗位承担模型应用、服务工程和数据工作的比例。再问团队怎样做评估与发布、入职前三个月希望完成什么。这些有助于判断工作是否匹配。

参考答案： 先确认用户、业务写入范围、数据源与完成条件。入口做身份和任务创建，编排层维护状态并选择工具，工具层接告警/设备/知识，审批层控制工单写入，事件层推送进度，存储层保存任务与操作。最后补上预算、权限、幂等、恢复和评估，不先画多 Agent。

参考答案：

op = 原子创建或读取操作记录(租户, 幂等键, 参数摘要)
如果参数摘要不同：拒绝
如果 op 已成功：返回原工单
如果其他执行者已领取：返回当前状态
校验审批版本、有效期和当前权限
领取执行权并记录提交意图
调用下游(同一幂等键)
如果成功：保存工单 ID 和成功状态
如果超时：保存结果待确认，进入核查流程
如果确定失败：按错误类型记录失败或安排重试

参考答案：

草案 → 待审批 → 已批准 → 执行中 → 成功
               ↓          ↓
              拒绝      结果待确认 → 核查成功 / 人工处理

修改关键字段：生成新方案版本 → 重新待审批
取消未执行方案：终止
取消已提交操作：先核查，再决定是否执行独立撤销流程

参考答案： 对每路列表按从 1 开始的排名累计 1/(k+rank)，以统一 ID 合并，同一路重复 ID 不重复计分，最后按总分排序并截断。还要保证两路数据版本与权限一致，并对并列分数设置稳定次序。k 控制排名贡献的平滑程度，不是召回条数。Elastic RRF ↗

参考答案： 找到请求及知识版本，检查解析内容是否正确、关键证据是否进入索引，再看过滤与召回、精排是否丢失证据、上下文是否被截断，最后检查模型生成。按链路定位，而不是第一反应更换模型或修改 Prompt。

参考答案： 固定候选集对比新旧排序，检查输入模板、截断长度、语言与领域适配，观察下降集中在哪类题。先确认是不是召回已丢失正确证据；必要时回退并缩小实验范围。相关性评分不能直接当成已校准置信概率。

参考答案： 先测瓶颈：模型配额、推理资源、数据库连接、检索还是事件流连接。根据数据做限流排队、并发控制、批处理或扩容；避免同时把所有层放大导致下游雪崩。达到资源边界时提供明确排队和拒绝策略。

参考答案： 选择一个明确场景，先接少量只读工具，输出带依据的排查建议，并建立小规模验收集。再加入工单预览与确认，最后完善恢复和监控。若时间不够，缩减功能范围，不省略写入权限与重复提交保护。

参考答案： 优先建立端到端评估与结构化任务状态，再用数据决定是否需要复杂编排或两套检索引擎。把模型依赖和业务工具契约隔离，降低替换成本。回答应对应真实遇到的问题，避免把所有未实现能力都说成下一步必做。

参考答案： 我会承认框架负责运行循环、状态抽象和事件等基础能力，再说明应用层的具体工作：数据如何清洗、证据如何判断、工具参数和权限如何约束、审批和幂等如何落到业务系统，以及如何测试。用一段自己实现的流程证明贡献，不争辩框架是否复杂。