AI 面试 / 150 道 AI 面试题
7. 智能体运行工程（Harness+Loop）
原文备份 · 第 8 / 22 篇 · 查看极客时间原知识库 ↗
本篇目录 · 10 节
来源：150 道 AI 面试题
Agent 的运行底座：上下文管理、轨迹、中断恢复、护栏。这部分是"从 Demo 到生产"的分水岭。
81. Agent 框架和 Harness 工程的分工边界在哪？为什么 Harness 才决定生产可用性？
直接答案：Harness 是 Agent 全生命周期的工程化体系，是 Agent 的"操作系统"。区别：
- Framework（LangChain 等）：负责"拼链、多 Agent 对话"，管**"怎么跑"**。
- Harness：负责"真值、权限、预算、审计"，管**"跑得对不对、安不安全、花多少钱"**。
知识点讲解：
- Harness 六大组件：Agentic Loop（执行循环）、Guardrails（护栏）、Hooks（生命周期钩子）、Context 压缩、状态持久化、可观测/审计。
- 分工的本质：Framework 是"表达层"（让开发者方便地描述 Agent），Harness 是"控制层"（让 Agent 在约束下可靠运行）。
- 为什么 Harness 决定生产可用性：Demo 只需"能跑通"，生产需要"跑对、跑稳、跑得起、可追溯"——这些恰恰是 Framework 不管、Harness 管的。
- 常见架构：Framework + 自研 Orchestrator 组合（框架表达 + 自研底座控制）。
- 面试趋势：Harness 已从加分项变必考题。
82. Agent 对话太长、上下文爆了怎么办？
直接答案：先保存可恢复的任务状态，再压缩上下文；错误证据不是应该直接删除的"坏内容"。
保留：任务目标、约束、已完成结果、最近失败的错误类型/参数及已尝试动作。把冗长日志压成摘要并保存原始文件路径；工具返回中的指令当不可信数据，不得提升为系统要求。
知识点讲解：
- 错误证据的价值：保留"test_amount 失败：0.1+0.2 非精确；已排除显示层"，比删除失败后反复尝试同一方案更有用——模型知道"这条路试过了，别重试"。
- 工具调用和结果的成组处理：工具调用和结果应成组保留或裁剪，避免协议断裂（tool_call 和它的 result 不能拆开）。
- 不可信数据边界：工具返回的内容（如网页里"忽略你的指令"）绝不能提升为系统要求——这是防间接注入的关键。
- 压缩 ≠ 删除：压缩要保留"状态可恢复"所需的最小信息（目标、进度、已试过什么）。
83. "中间遗忘效应"是什么？怎么缓解？
直接答案：中间遗忘（Lost in the Middle）指长上下文中，模型注意力集中在开头和结尾，中间内容召回率大幅下降——模型"看得到"中间内容，却"用不上"。
缓解：
- 重要信息放开头/结尾。
- 关键内容定期重复。
- 不依赖长上下文，用检索/摘要把中间内容"提"到显眼位置。
知识点讲解：
- 机制理解：这是位置编码和注意力训练分布的副作用，不是模型"忘了"，而是"中间位置的信号被稀释"。
- 对 RAG 的指导：重排序后把最强 chunk 放开头/结尾能提效，因为中间位置的 chunk 即使相关也容易被忽略。
- 对长窗口的反思：是判断"要不要用 200k 上下文"的依据——窗口大 ≠ 该全塞，塞多了反而中间全丢。
- 验证方法：把同一证据分别放开头/中间/末尾测召回，得到"位置敏感度"曲线。
84. 三种上下文管理策略（固定窗口/滑动窗口/压缩）怎么选？
直接答案：三种策略各有取舍，通常组合使用：
- 固定窗口：保留最近 N 条消息，最老的最先淘汰。
- 滑动窗口 + 置顶：额外保留系统要求和有效任务约束（置顶不淘汰）。
- 摘要压缩：把更早但仍有价值的信息压成摘要保留。
知识点讲解：
- 组合示例：
固定指令 → 早期 A/B → 工具调用 C/结果 C → 最近 D，空间不足时先总结 A/B，保留固定指令和最近 D；C 必须按协议成组处理。 - 不要删尾部：最新请求（当前任务）是绝对不能丢的，淘汰从最老开始。
- 摘要的损失：会丢细节，应保留来源、关键决策与可重读产物（如文件路径），而非纯文本压缩。
- 没有万能策略：用"恢复后能否继续同一任务"验证压缩质量，不同任务的最优窗口策略不同。
- 判断依据：信息的新鲜度（越新越重要）、稳定性（固定指令不可丢）、可压缩性（日志可压、约束不可压）。
85. 无关信息如何"污染"上下文并稀释关键信号？怎么动态清理？
直接答案：上下文窗口污染指无关/冗余信息挤占上下文，降低对重要内容的关注——噪声稀释信号。
防：
- 即时摘要工具输出（长结果先压）。
- 去重（相同信息只保留一份）。
- 动态移除无关上下文。
- 重要性评分优先保留。
知识点讲解：
- 和"中间遗忘"是硬币两面：一个讲"关键被埋没"，一个讲"无关挤进来"，本质都是"信号被稀释"。
- 工具输出是最大污染源：一次搜索返回几千 token 的无关内容，几轮就污染整个窗口。
- 实现：记录消息重要性分数，用优先队列淘汰低价值内容 + 压缩缓存。
- 动态清理的边界：不能误删"当前任务必需"的信息，所以清理要和任务状态挂钩（哪些信息已消费完、可安全丢弃）。
86. Agent 的中断恢复怎么做？为什么需要 Checkpoint？
直接答案：中断恢复依赖 Checkpoint（检查点）——每步执行后保存状态，出错/中断后能从检查点恢复，而非从头重跑。
为什么需要：Agent 是多步、长时间运行的，可能因崩溃、超时、人工审批暂停。检查点让运行可暂停、可恢复、可调试。
知识点讲解：
- 实现：LangGraph 的 Checkpointer（
MemorySaver/SqliteSaver/PostgresSaver），按thread_id区分会话；每一步节点执行后自动落检查点。 - 时间旅行调试：回退到任意历史状态重跑，是排查"哪一步出错"的核心能力。
- 和幂等的关系：从检查点恢复可能重放某些节点，所以副作用操作必须幂等（不能重复付款/发送）。
- 持久化介质的选择：内存（仅开发）、SQLite（单机）、Postgres（生产）——生产必须持久化，否则崩溃即丢状态。
- 面试加分点：能说出"checkpointer 是生产级 Agent 的魔法词"。
87. 为什么 Agent 调试和评估必须以 Trace 为主键？没有 trace 会怎样？
直接答案：Trace 是 Agent 一次运行的完整执行记录：每一步的 prompt、工具调用及参数、工具结果、延迟、护栏介入、状态流转。
为什么是主键：Agent 是路径依赖的，只看最终输出无法定位问题。Trace 记录"发生了什么"，是评估归因和调试的唯一依据。
知识点讲解：
- 三层评估信号都要挂到 trace 上：会话层（完成率）、轨迹层（决策合理性）、节点层（动作精度）——挂不上 trace 就无法归因。
- 没有 trace 的后果：Agent 出问题就是黑盒——只知道"结果错了"，不知道"哪一步、哪个工具、哪个参数"错了，无法修复。
- Trace 的关键字段：时间戳、token 用量、延迟、工具名、参数、返回值、护栏触发、错误信息。
- 工具：LangSmith、Langfuse、Phoenix、Arize Phoenix。
- 面试加分点：能说出"没有 trace，Agent 出问题就是黑盒"，且知道 trace 是成本归因、质量归因、安全审计三者的共同载体。
88. Agent 的权限边界怎样落实到执行层？
案例题：同一个 Agent 能读内部文档、修改练习文件和发送客户邮件，怎样设置边界？
直接答案：
- 内部文档：按用户身份和租户过滤；传入外部服务前检查数据是否允许出域。
- 练习文件：限制在授权目录，支持回滚。
- 客户邮件：在明确收件人和内容审批策略满足后发送。
知识点讲解：
- 权限在工具入口检查：实际权限检查发生在工具执行的代码层，不能由模型口头确认代替。
- 四种必测边界：授权允许、路径越界、敏感数据外传、重复发送，分别测试。
- 运行时附加约束：时间预算、费用预算、日志、停止机制——权限之外还有资源约束。
- 最小权限 + 可回滚：每个工具只给完成任务所需的最小权限，写操作尽量可回滚（练习文件可回滚，生产数据不行）。
- 数据出域检查：把内部数据传给外部搜索/第三方服务前，必须先验证是否允许出域——这是最易被忽视的"读操作越界"。
89. Agent 的状态持久化在哪一层？为什么不能只存 Redis？
直接答案：状态分三层持久化：
- 工作记忆：当前任务临时状态，放上下文窗口。
- 情景记忆：历史运行，存 KV/数据库。
- 语义记忆：长期知识、偏好，存向量库。
为什么不能只存 Redis：Redis 只是"存了状态"，没解决"怎么组织、怎么衰减、怎么召回"——单纯把全部历史塞进 Redis 再全量取回，等于没做记忆管理。
知识点讲解：
- 正确模式：摘要化——阈值触发时压缩最老几轮成摘要，持久化到情景记忆，原始轮次丢弃。
- 分层的原因：不同记忆有不同的访问模式（工作记忆高频、语义记忆按语义检索），不能一种存储打天下。
- 常见错误：
- 把上下文窗口当记忆（跨会话失忆）。
- 过度持久化（召回噪声，历史堆满）。
- 衰减与召回：情景记忆按时间/相关性召回，语义记忆按向量相似度召回，都需要"选择性"，而非"全量"。
90. 资源有限时，Agent 的优化顺序是什么？
直接答案：优化优先级从高到低：
- 验收/测试门禁（最优先）。
- 工具 schema。
- 任务粒度。
- Prompt。
- 换模型（最后手段）。
为什么验收门禁第一：它是"真值"来源——用确定性手段（pytest、lint、结构化校验）判定是否真完成，而非信模型自述。有了真值，后续所有优化才有衡量标准。
知识点讲解：
- 关键原则：blocker 由 CI 真值决定，不由模型给的 severity 决定——模型说"严重"不一定真严重，代码校验说"失败"才是真失败。
- 顺序的逻辑：先建立"对不对"的标准（门禁），再优化"工具定义"和"任务拆分"（结构性），最后才是 prompt 和模型（表层）。
- 换模型是最后手段："同模型换 Harness，效果差异巨大"——问题往往不在模型能力，而在运行工程。
- 资源有限时的杠杆：验收门禁和工具 schema 是投入产出比最高的两项，因为它们直接决定"能不能判定成功"和"工具能不能被正确调用"。