DeepSeek AI Agent 开发岗社招一面（9.8）：Harness、评测回流、取消与多租户 Agent 平台

《面试题目》

一、Harness 与架构

1. 你最近在关注 Agent 领域的什么新技术？你说你关注了 DeepSeek-Harness，你怎么理解它和 LangChain 的本质区别？Harness 解决了什么 LangChain 解决不了的问题？
2. 你的 Agent 整体架构分几层？每层职责是什么？层与层之间的接口怎么设计、为什么这么设计？换一种分层方式会有什么不同？
3. 你的 Agent 用的是 ReAct 还是 Plan-and-Execute？为什么选这个？如果任务更复杂（比如 50 步的长链路），你的方案还 work 吗？怎么改进？

二、多 Agent 与评测

4. 多 Agent 协作是怎么实现的？通信模式是什么？如果子 Agent 返回的是自然语言而不是结构化数据，主 Agent 怎么解析？怎么保证解析不出错？
5. 你的 Agent 评测体系是怎么搭建的？评测集覆盖了多少场景、怎么构造？如果评测集里 30% 的 case 答案有主观性，你怎么处理？
6. Badcase 怎么回流到训练/优化流程？你是不是直接把失败轨迹拿出来重新做 SFT？如果是，有什么问题？如果不是，完整处理链路是什么？
7. 如果 Agent 效果不达预期，你怎么判断瓶颈在哪？是模型能力、工具调用不准、上下文丢失，还是评测标准有问题？怎么区分？

三、运行时细节

8. Agent Loop 的核心设计是什么？每一步的输入输出格式是什么？如果 LLM 返回的 Tool Call 不合法怎么处理？如果执行完工具后观察结果太长怎么截断？
9. 如果 Agent 跑了 20 分钟还没结束、用户等不及要取消，你的系统怎么响应？取消后已经在执行的工具调用怎么处理？任务状态怎么回滚？
10. 上下文压缩时你怎么做信息丢失的评估？用模型打分还是规则？如果压缩丢了关键信息导致后续决策错误，你能检测到吗？怎么恢复？

四、行业判断

11. 怎么看待现在的 AI Coding 工具（Cursor、Claude Code、Codex）？你觉得它们最大的瓶颈是什么？如果让你做一个更好的，你会怎么设计？
12. 你觉得 3 年后的 Agent 开发框架会和现在有什么不同？Harness 会变成什么形态？模型和工程的分界线在哪里？
13. 如果你来做 DeepSeek-Harness 的下一个版本，你会加什么功能？
14. 你读过 DeepSeek-Harness 的源码吗？核心设计亮点是什么？有什么可以改进的地方？
15. 除了 Harness，你还关注哪些 Agent 方向的开源项目？你 Fork 过吗？提过 PR 吗？

五、设计题与手撕

16. 设计一个「多人协作的 Agent 平台」，支持多个用户同时使用、每个用户可以创建多个 Agent、Agent 之间可以协作。多租户隔离怎么做？Agent 之间的通信怎么设计？权限控制怎么实现？
17. 实现一个简单的 FST（有限状态机）来管理 Agent 的状态，状态包括 INIT、PLANNING、EXECUTING、CHECKING、COMPLETED、FAILED，状态转换的触发条件是什么？

六、反问

18. 团队当前更核心的 Agent 问题是模型能力、工具调用、上下文工程、评测体系还是运行时基础设施？未来半年最重要的技术目标是什么？
19. 线上主要优化哪些指标：任务成功率、人工替代率、事实一致性、延迟、token 成本，还是高风险操作的安全性？这些指标如何定义和归因？
20. 当前系统更偏固定 Workflow、ReAct、Plan-and-Execute 还是混合架构？什么条件下会从 Agent 退回确定性流程？团队如何做评测集、灰度与 badcase 回流？岗位在模型训练、Agent Runtime、代码基础设施与业务落地之间的职责比例怎样？

《参考解析》

Harness 与 LangChain 的边界。 LangChain 解决的是「怎样快速把 Prompt、模型、检索器、工具、解析器组装成一次调用链」，它的抽象中心是组件与编排；Harness 关注的是「这次多步任务如何在不确定、可失败、有副作用的环境里可靠运行」——维护状态机与执行循环、把模型输出解析成下一步动作、校验工具调用、执行受控副作用、写事件轨迹、处理中断/超时/重试/恢复/停止条件，并为评测与训练保留完整轨迹。举例最有说服力：模型说「转账」，LangChain 可以把这个意图串到工具上，但 Harness 要在真正执行前做 schema 校验、用户授权、金额上限、幂等键、审计留痕。所以两者不是替代关系：可以用 LangChain 做模型与工具适配，再叠一层自研 Harness 管状态、策略、观测与恢复。Harness 也治不了模型本身的推理与事实性。

分层与接口。 一个能讲清的划分是：接入层（鉴权、会话、流式协议）／编排层（计划、状态机、调度、预算）／执行层（模型适配、工具执行、沙箱）／数据层（会话与产物、检索、审计）。层间接口要窄且结构化：编排层只向下要「执行一个动作并返回结构化观察」，不关心是哪个模型或哪个工具；执行层不持有业务状态。这样换模型、换工具、加评测都不用动上层。换一种分层（比如把状态放进 Prompt、把权限放在工具内部）的代价要能说清：不可恢复、不可审计、越权。

ReAct 与 Plan-and-Execute。 ReAct 是「想一步做一步」，适合探索性强、路径不可预知的任务，但步数一多容易漂移、重复、上下文膨胀；Plan-and-Execute 先出计划再执行，适合步骤可枚举、依赖清晰的任务，但计划本身可能错，需要重规划。50 步长链路的正解不是把 max_steps 改成 50，而是：任务分段与层级规划、每段有完成条件与验收、阶段性 checkpoint、依赖图、错误预算、幂等执行、局部重试、全局超时与人工接管；上下文也不该保留全部原始 observation，而是把每步压成结构化状态（未完成目标、已确认事实、工具结果引用）。

多 Agent 通信。 不要让 Agent 之间互发自由文本再靠正则解析——用带 schema 的消息协议：message_id / tenant / task_id / parent_step_id / sender / receiver / schema_version / type / payload / evidence_refs / deadline / idempotency_key / state_version。编排器维护任务 DAG，能并行的子任务入队；子 Agent 返回结构化结果 + 证据 + 置信度 + 副作用记录；Reducer 按任务版本合并，冲突进仲裁或人工队列。至少一次投递时靠 message_id 与幂等键去重。若确实只能拿到自然语言，就做「结构化抽取 + schema 校验 + 失败重问」，并把抽取失败率当指标监控，而不是写一堆容错正则。

评测与主观 case。 评测集按「任务类型 × 难度 × 工具组合 × 已知失败模式」铺矩阵，而不是只看条数。指标分层：结果（任务成功率、事实一致性、人工替代率）、过程（工具选择准确率、参数合法率、步数、重规划次数）、体验（首字延迟、总时长）、成本（每成功任务 token）。30% 主观 case 的处理是：先写评分细则（rubric）把主观拆成可判定的维度，再用双模型/双人交叉评 + 抽样人工校准，报告一致性系数而不是只报平均分；对分歧大的样本单独成集，定期复核。

Badcase 回流。 直接拿失败轨迹做 SFT 是最常见的错：失败轨迹里混着「错误的中间步骤 + 偶然正确的结论」，模型会学错过程；而且单条轨迹往往有多种合理解法，硬拟合会窄化策略。正确的链路是：失败轨迹先归因（模型能力 / 工具描述 / 上下文 / 环境 / 评测口径），能靠工程修的（工具 schema、重试策略、上下文组装）就不要动模型；确实属于能力问题的，改写成「问题 + 正确过程 + 验收」的训练样本或偏好对，进回归集防退化，再小流量灰度。

瓶颈定位。 用消融把变量分开：换更强模型看是否提升（模型能力）、固定模型只改工具描述与参数 schema（工具调用）、固定一切只把关键事实强制放进上下文（上下文丢失）、人工按同一 rubric 复评同一批输出（评测口径）。再加过程指标：工具调用非法率、平均步数、重规划频率、压缩后任务成功率下降幅度。能定位到某一层的，才是有效结论。

Agent Loop 与取消。 循环每一步的输入是「结构化状态 + 新增观察 + 可用工具」，输出是「动作（文本或 tool_call）」，服务端必须重新校验工具名与参数、鉴权、预算与副作用，再执行并把结果按调用 ID 写回。工具调用不合法时不要直接抛给用户：一次「纠错重问」（把 schema 错误回给模型）后仍失败就降级为明确失败并记录；未知异常不重试，可重试异常限次数。观察太长时按「摘要 + 引用」截断，保留结构化字段、丢弃重复文本、大产物落盘只留句柄。取消要沿调用链传播：停止派发新步骤、给在途工具发取消信号、只提交已完成的前缀、对不可撤销的副作用做补偿记录；任务进 CANCELLED 而不是 FAILED，并保留可恢复快照。

压缩的信息丢失评估。 规则 + 模型两条腿：规则侧对关键实体（数字、金额、日期、否定条件、权限、待办）做「压缩前必须出现、压缩后仍在」的校验；模型侧用固定 rubric 打分（事实保真、约束保留、可继续执行）。更强的做法是「任务级验证」：拿压缩后的状态继续跑下游步骤，看成功率是否下降——这比任何打分都贴近真实损失。发现丢失时靠可恢复设计兜底：摘要只做导航，关键证据保留指针（文件路径、消息 ID），需要时回取原文；状态写入 checkpoint，出错可回滚到上一个已知良好状态。

行业判断类问题。 AI Coding 工具的瓶颈不在生成代码，而在「验证」与「上下文获取」：模型能写，但判断对不对仍要人跑测试、读差异；仓库越大、约定越多，上下文越难给全。做更好的产品，方向是把验收条件变成可执行检查、把项目约定沉淀成长期上下文、把失败样本变成回归集，而不是把对话窗口开得更多。3 年后 Harness 大概率会「下沉」：状态、重试、权限、审计变成基础设施，模型与工程的界线移到「谁定义验收、谁承担副作用」。这类题没有标准答案，给判断 + 依据 + 反例即可。

多人协作 Agent 平台。 资源层级 tenant → user → workspace → agent → task → run → step，每条资源都带 tenant_id，租户由服务端从认证身份推导，禁止信任客户端传的租户字段；数据库用租户条件/行级策略或独立 schema。控制面集中（编排、配额、审计），执行面可水平扩展（沙箱化 worker）。权限三层：RBAC 管角色、ABAC 管「租户 + 资源归属 + 数据等级 + 环境」这类条件，工具凭证用短期最小权限 token 且每次调用服务端重新鉴权——不能因为模型选了工具就放行。再补配额、限流、超时、取消、审计、密钥轮换与数据删除；日志默认不落完整 Prompt 与敏感返回。

手写 FST。 显式定义状态集、事件集、合法转移与副作用，用转移表驱动而不是一堆 if：INIT 校验通过 → PLANNING，校验失败 → FAILED；PLANNING 计划通过校验 → EXECUTING，计划非法/超预算 → FAILED；EXECUTING 工具完成 → CHECKING，可恢复错误且重试预算未耗尽 → 留在 EXECUTING，不可恢复/取消/超时 → FAILED；CHECKING 验收通过 → COMPLETED，不通过且可重规划 → PLANNING。要点是：非法转移要显式拒绝并记日志，状态变更与副作用要能一起提交（或至少可重放），COMPLETED/FAILED 是终态、不允许被迟到的事件改写。

反问。 高质量反问围绕「目标、约束、证据、责任边界」：团队最痛的是哪一层、线上怎么定义成功、什么条件下会从 Agent 退回确定性流程、版本与回滚怎么管、这个岗位前三个月要解决哪个具体问题。听到回答后追问一个具体指标或失败案例，比问「团队氛围怎么样」有效得多。