《Agent面试详解》系列上篇运行时与上下文 · 中篇记忆、工具与并发待发布 · 下篇评测、安全与落地待发布最近刷到几段讨论 DeepSeek Agent 岗位和面试的视频。里面反复出现的问题很有代表性上下文窗口怎么选多用户并发怎么处理长期记忆会不会无限膨胀一个 Agent 跑几十步以后为什么越来越不稳定。这些问题表面上像面试题实际已经越过 Prompt 和框架用法进入运行时、分布式系统、数据治理和工程架构的范围。DeepSeek 的公开招聘也能印证这个变化。当前职位列表中已经出现 Agent Harness、Agent Infra、Agent 后端和 Code Agent 数据等不同方向。它需要的不是一个“会调模型 API 的人”而是一支能把模型能力变成稳定产品的完整团队。DeepSeek 官方招聘这个系列不整理“面试题标准答案”而是从零设计一套企业级 Agent。假设它支持多租户可以连续执行 100 步能访问内部与外部工具进程崩溃后可以恢复高风险操作必须审批所有行为可以审计和评测。上篇先处理底座模型、Harness 和环境是什么关系运行时如何保存状态长任务为什么会失控上下文窗口应该怎样管理。DeepSeek 最近在招什么人Agent 这个词过去太宽泛。一个聊天框接上搜索 API也有人叫它 Agent一个可以操作代码仓库、跑几小时、修改外部状态的系统也叫 Agent。两者显然不是同一种工程问题。DeepSeek 当前公开岗位把边界划得更清楚Agent Harness 团队、Agent Infra、Agent 后端、Code Agent 数据、搜索算法与架构分别承担不同工作。可以用一个简化公式表达这种分工Model Harness Agent如果把真实工作环境也纳入系统公式还要再补一项Model Harness Environment Agent System模型负责理解、推理和生成决策Harness 决定模型能看到什么、能调用什么、怎样保存状态、失败后如何恢复Environment 则提供代码仓库、浏览器、数据库、业务 API 和权限边界。离开后两层模型再强也只能在对话框里给建议。近期的 Harness Engineering 研究把这层运行时拆成任务定义、上下文选择、工具访问、项目记忆、任务状态、可观测性、失败归因、验证、权限和人工干预等职责。它强调的不是“模型能否生成一个 patch”而是整个系统能否交付一个可验证、可归因、可维护的修改。AI Harness Engineering这也是 Agent 面试变硬的原因考察对象从某个框架的 API变成了一个完整软件系统。先把企业级架构画出来先不要急着讨论 LangGraph、AutoGen 或某个 SDK。框架选型之前应该先确定系统边界。一套可以长期运行的企业 Agent至少需要下面这些模块。模块主要职责不应该负责什么API Gateway认证、租户解析、限流、请求入口不编排 Agent 步骤Run Manager创建、去重、取消、恢复和查询 run不直接执行工具State Machine驱动 Agent Loop约束状态迁移不保存全部业务数据Planner拆任务、维护依赖、触发重规划不绕过权限调用工具Context Builder组装每一轮模型输入不把数据库当成聊天记录倾倒Model Router按难度、风险、延迟和成本选模型不决定业务权限Scheduler排队、并发、租约、重试和背压不持有长期数据库事务Tool Gateway发现、校验、授权和执行工具不暴露 Secret 给模型Sandbox隔离 Shell、浏览器和代码执行不承担全局调度Memory Service记忆写入、合并、检索和遗忘不控制 Agent LoopApproval Center审核高风险和不可逆操作不替模型补参数Trace / Eval记录轨迹、证据、指标和评测结果不反向污染运行状态模块之间怎么通信短查询可以走 HTTP 或 gRPC例如 Run Manager 查询一个 run 的状态长操作应该进入消息队列例如一个需要运行十分钟的浏览器任务。状态变化最好发布版本化事件而不是让所有模块直接读写同一批表。有三条边界尤其重要Tool Gateway 不应依赖 Planner 的内部对象只接受稳定的 Tool Call Contract。Memory Service 不应知道某个框架的 message class只存储有版本的领域对象。数据库事务不能跨模型调用、工具调用、文件 I/O 或网络 I/O。如果多个模块共享 ORM 对象、共享进程内全局状态、共享一条长事务系统在单机 Demo 里很方便到了多 Worker、重试和滚动升级时就会迅速失控。Agent Loop 怎样从 Demo 变成运行时最小 Agent Loop 通常写成这样while not done: response model(messages, toolstools) if response.tool_call: result execute(response.tool_call) messages.append(result) else: done True它适合教学不适合企业运行。至少缺少状态持久化、预算、取消、错误分类、并发控制、审批和完成证据。更接近真实系统的循环是读取 run 与 checkpoint → 构造本轮上下文 → 模型规划下一动作 → 策略与权限检查 → 执行工具或等待审批 → 持久化 observation → 更新任务状态 → 验证完成条件 → 继续、重试、重规划、暂停或结束每一步都要能够回答三个问题这一步的输入来自哪个版本的状态这一步是否已经产生外部副作用进程现在崩溃下一台 Worker 从哪里继续“完成”不是模型说了算模型输出done只能表示它认为自己完成了。系统还要运行验证器。例如代码 Agent 必须检查目标测试、相关回归测试和工作区 diff数据 Agent 必须核对查询范围、行数和口径客服 Agent 必须确认工单状态确实改变。完成条件应该是机器可观察的状态completion: required: - target_tests_passed - regression_tests_passed - no_unapproved_side_effects - final_evidence_attached max_steps: 100 max_duration_seconds: 7200这里的max_steps是安全上限不是让 Agent 必须跑满 100 步。真正的结束条件来自证据预算只负责在异常时切断循环。跑到五十步为什么容易崩长任务最先碰到的通常不是模型智力而是上下文管理。如果每次工具调用都把原始结果追加到messages上下文会持续膨胀。更麻烦的是Token 变多不只意味着成本变高还意味着关键约束被大量 observation 淹没、旧错误继续传播、模型开始重复已经做过的工作。不要只按“最近 N 轮”截断固定保留最近 10 轮很简单但不可靠一次浏览器 DOM 或日志输出可能比十轮普通对话还长而第 11 轮恰好可能保存了不可丢失的架构决策。更稳妥的是按 Token 预算组装混合窗口固定区system policy、目标、权限和不可变约束 任务区当前 plan、未完成步骤、最近 checkpoint、关键决策 动态区最近交互、本步工具摘要、按需检索的记忆 预留区模型输出、Tool Schema、下一轮 observation阈值怎样设不能等模型 API 返回“context too long”才处理。一个可落地的初始方案是上下文水位动作60%–70%开始监控重复内容工具大结果只保存摘要75%–80%生成 checkpoint压缩旧轨迹85%大型原始结果全部外置只保留引用和关键事实90%停止扩展任务不再接收不可预测的大结果接近硬限制从 checkpoint 启动新线程或交还人工真正的输入预算不是模型标称上下文上限可用输入预算 上下文上限 - 最大输出预算 - Tool Schema - 安全预留 - 序列化与格式化开销建议至少留出 10%–20% 给输出和不可预测增长。对于会返回大结果的浏览器、日志和数据库工具预留还要更高。阈值不是行业标准应根据真实轨迹、模型输出长度和工具分布持续校准。溢出前的兜底顺序删除可以重新获取的原始工具结果。合并重复 observation。把旧步骤压缩成带证据引用的 checkpoint。只加载当前阶段需要的工具定义。将独立工作拆给 Subagent隔离上下文。冻结旧线程用结构化状态启动新线程。仍无法压缩时暂停而不是静默丢掉约束。DeepSeek 的上下文缓存可以降低相同前缀的延迟和成本但缓存并不能解决上下文语义污染。它优化的是重复计算不是信息选择。DeepSeek Context Caching上篇留下的接口到这里Agent 已经有了运行时骨架每一步受状态机约束慢调用不占用数据库事务完成依赖证据上下文按预算组装进程可以从 checkpoint 恢复。但状态能够恢复不代表长期记忆可信工具能够调用也不代表它不会越权或重复产生副作用。中篇继续处理最容易把 Demo 拖垮的三件事记忆、工具和多用户并发。**接下来**中篇将继续讨论记忆、工具与多用户并发暂未发布。《Agent面试详解》系列上篇运行时与上下文 · 中篇记忆、工具与并发待发布 · 下篇评测、安全与落地待发布