Agent 从 Demo 进入生产后，工程约束随之改变。它不仅要完成一次任务，还要在峰值流量到来时快速拉起，在多轮交互中持续保留状态，在不同用户之间守住数据边界，并在大量空闲等待中控制成本。前程无忧 AI 招聘助手的落地过程，呈现了这些问题如何从产品设想一步步变成生产系统必须回答的工程命题。

随着模型持续迭代、不同规模的模型进入应用，企业开始有更多选择来组织 Agent 的能力与成本。Agent 也从对话入口走向能够拆解任务、调用工具并根据执行反馈继续行动的系统。对业务团队而言，关注点由模型能回答什么，进一步转向 Agent 能否完成实际工作，以及如何把它接入已有产品和业务流程。

在应用形态上，桌面助手与云端数字分身强调端云协作：用户通过本地端或即时通信入口交互，云端沙箱承接持续运行的任务；企业级 Agent 则围绕垂类业务组织提示词、工具和私有数据，用户级鉴权与记忆隔离成为重要要求。企业既可以选择托管方案，也可以在成熟 Harness 上扩展，将开发投入更多放在业务 Skill、MCP 与数据上。

这些变化对应着运行对象的改变。微服务时代的基础设施主要承载服务或函数，交互以请求与响应为主，长期状态通常外置到数据库或缓存。Agent 则需要长会话、多轮交互和持续待命，任务中可能等待模型响应、用户输入或网页加载，执行环境需要保留工作状态，并隔离不同会话和任务。

旧 Infra 为“微服务”而生：无状态、用完即走；Agent 是“有状态、长会话、强隔离、大规模”的新物种。Infra 必须从“跑服务”，演进到“跑 Agent 的沙箱运行时”。

阿里云智能体沙箱 Agent Sandbox （以下简称 Agent Sandbox）的本质是专为 Agent 量身定制、具备完整操作系统级能力的“云上超级计算机”。它必须足够真实，让 Agent 能完成复杂任务；也必须足够受控，让企业敢把它接入生产系统。

这一运行环境包含相互配合的能力：MicroVM 或 VM 提供计算隔离，浏览器与电脑使用能力承接真实交互，文件工作区保存项目和依赖；网络策略通过 VPC、白名单和 ACL 控制访问，会话亲和、休眠与恢复支持持续交互；日志、Trace 和录屏用于审计回放，身份凭证与短期 Token 隔离配合访问授权，实例创建、恢复和销毁则组成弹性生命周期。

执行环境的隔离之外，工具调用还需要与用户身份和权限对应。同一企业系统中，不同员工能够访问的数据、执行的操作并不相同，Agent 接入工具不能抹平这些差异。Agent Identity 用于衔接工具调用与身份权限；凭证外置则避免把长期 API Key 直接放在沙箱中，使模型不必接触工具的真实密钥。这些能力分别处理执行边界、授权与凭证暴露问题，不能仅凭进程隔离或密钥外置就认定整个链路绝对安全。

受控的执行环境为 Agent 提供了运行基础，但沙箱具体承接什么工作，还取决于 Agent 的运行方式：它可以只执行一次工具调用，也可以承载持续运行的 Agent，还可以用于批量训练与评测。这些工作在运行时长、状态保留和创建频率上的差异，对沙箱提出了不同要求。前程无忧的招聘助手属于第二种：Agent 运行时直接在沙箱中执行，持续承接 HR 的招聘任务，因此更关注会话亲和、休眠恢复与空闲成本。

Agent Use Sandbox 把沙箱作为外部工具执行层，用于 Code Interpreter、Browser Use、Computer Use，以及 MCP Server、Skill 等执行场景。它的负载周期短、创建频繁、流量容易突发，因此需要低延迟创建、快速销毁与强隔离。

Agent In Sandbox 则把 Agent Runtime 或 Harness 直接运行在沙箱中，适用于 Coding Agent、长任务 Agent、数字分身、个人助手和多 Agent 协作。此类负载生命周期长、状态依赖强，但活跃率可能较低，大量时间用于等待模型、用户或网页。因此，会话亲和、休眠恢复与低空闲成本成为持续运行的重要条件。

Agent RL / Eval 面向批量 Rollout、Trajectory 采集、实例 Fork、回放和大规模评测，环境创建吞吐影响训练与评测效率。这类负载对基础设施提出十万级并发、秒级启动与 Checkpoint 等要求。

招聘平台连接招聘方、求职者和平台本身，各方掌握的信息并不相同。招聘方对薪酬、人才供给和岗位要求的判断，可能与求职者的预期存在差异；平台内部的搜索、推荐和业务规则，也未必能被每位用户充分理解和使用。AI 带来的机会，是让这些信息更容易被理解，让原本难以通过产品界面表达的要求能够进入交互过程。

招聘方首先要回答“招什么样的人才”，但用人需求常常模糊，涉及具体行业经验等细粒度要求。随后是“怎么快速找到人才”：固定搜索字段和规则很难覆盖全部个性化需求。如果暂时找不到匹配人才，平台还有其他搜索建议和解决方案，但客户未必知道如何使用。

因此，前程无忧提出将招聘功能逐步 AI 化的产品设想，不只提供一个问答入口，而是围绕找人、简历筛选、沟通、面试和市场分析组织能力。整体架构分为应用场景、智能体能力、数据与技术底座三层：应用层覆盖精准找人、AI 淘金、AI 初筛、AI 面试、招聘效果诊断等方向；智能体层包含意图理解与多轮对话、长短期记忆、Agent 编排与工具调用、语义匹配与推荐排序、多模态理解；底座由大模型服务、云沙箱运行时、招聘数据资产、安全与合规、Skill 与工具共同支撑。

产品设想扩展之后，早期自研 Agent 框架的局限随之显现。V1.0 框架缺少能够根据执行反馈自我纠正的 Loop，同时需要持续投入开发和测试人力。面对 Skill、MCP 等组件快速演进，框架成型的速度难以跟上技术变化，也难以承接不断扩展的业务计划。

下一阶段的选择，是使用成熟框架，将人力重新投入核心业务。Agent Sandbox 极速版与 Developer API 为这一尝试提供运行基础，前程无忧在沙箱中组合 Agent Runtime、Skill 与 MCP，不再把补齐自研 Harness 作为主要投入方向。

实践约用一个月跑通 POC、约三个月完成 MVP。MVP 阶段验证能否基于 FC、QwenPaw 搭建可用方案，并围绕最小可用功能持续打磨；MMP 阶段，精准搜索功能开始获得用户付费；随后围绕用户提出的“我们要更多”，继续扩展功能，推进 MLP 阶段。从方案验证到用户付费，再到根据反馈丰富功能，招聘助手逐步进入真实业务。

可用功能跑通之后，问题从开发验证转向生产运行：HR 的访问集中在早间，尤其是九点到十点，可能形成万级规模的脉冲；每个 HR 的对话和岗位数据需要独立管理；会话集中到来时要快速准备环境；运行和对话数据还需要留痕、存储、审计与分析。万级规模、弹性调度、隔离与安全、存储与数据闭环，构成下一阶段的四重挑战。

前程无忧 AI 招聘助手 V2.0 的接入端是招聘平台，HR 创建或维护岗位形成岗位会话事件，由会话编排层组织账号、会话与实例关系。客户实践按 HR 账号提供独立 Agent 与 Sandbox，HR 名下的不同岗位拥有各自工作目录；实例内部运行 51Paw Agent Runtime，岗位数据写入相应工作空间。

工作目录按 HR ID 与岗位会话 ID 组织，路径为 /ai_hr_recruitment_{hrID}/{job_session_id}。持久化存储承接高并发实例挂载与读写，运行日志、调用轨迹和对话内容进入 SLS 审计链路，再投递至 MaxCompute 支撑分析。计算实例与持久化岗位数据分别管理，使实例生命周期变化时，系统仍可通过对应目录读取保留的数据。

实例治理采用定时预留与 TTL 配置。架构设计中，预留实例每天 08:00—20:00 定时拉起，未绑定实例的 TTL 配置为 1800 秒，绑定岗位后为 86400 秒，同时维护预留实例与账号实例的绑定关系。招聘完成、岗位下架等业务事件也被纳入实例回收治理。定时预留与回收配置共同服务于集中访问时的容量准备和日常资源管理。

生产链路还包括模型流量治理与企业级 Skill 市场。前者承接鉴权、限流和模型调用审计，后者组织项目级 Skill 分发、上架治理与安全扫描。它们与会话、实例、存储及审计共同配合，支持招聘助手进入持续运营。

HR 并不会持续满载地使用招聘助手。完成一轮筛选后，用户可能转去处理其他工作，稍后再回到原岗位。如果始终保留全部活跃计算资源，等待期间会产生空闲成本；如果每次离开都销毁环境，下一次交互又要重新准备运行时，难以兼顾交互连续性与资源利用。

客户将正在请求、刚刚离开和较长时间无交互的用户，分别对应到活跃、浅休眠和深休眠状态，利用沙箱的休眠与唤醒能力降低等待期间的资源开销。浅休眠保留内存状态，CPU 不冻结，而是以低功耗方式运行，后台任务仍可在这一状态下执行。当业务请求到来，或后台任务的 CPU 消耗超过低功耗状态时，系统切回活跃状态；后台任务超过这一条件后，按活跃价格计费。

Agent Sandbox 支持浅休眠实例的并行唤醒，避免已有环境恢复活跃时重复经历从零创建和加载过程，其浅休眠实例唤醒时间的产品口径为 1 毫秒。浅休眠期间 CPU 免费、内存继续计费，资源计费状态随实例活跃情况变化。

客户实践中，单会员日成本的现场估算约为 1 元，具体成本受到商业模式影响。通过休眠状态管理，持续待命的招聘助手得以在用户交互与空闲等待之间切换资源状态，将成本治理纳入生产运营。

休眠与恢复改变了实例的资源状态，招聘任务仍需要清晰的数据边界。前程无忧通过账号级沙箱隔离不同 HR 的运行环境，再结合运行时的会话隔离和岗位独立工作目录，管理同一 HR 下的多个岗位。

通用 Agent Sandbox 方案提供会话独占并绑定实例的方式，会话亲和使用 Session ID 将后续请求路由到对应实例；会话粒度的存储粘性，则把会话与归属特定租户的持久化子目录绑定。动态挂载不要求为挂载操作重启沙箱。前程无忧以 HR 账号组织实例、以岗位会话组织目录，将运行环境与业务数据分别管理。

从深休眠返回时，实例先启动，再挂载对应目录，继续读取保留的消息与岗位数据。前程无忧的会话数据一般保留 180 天，在保留期内可供后续交互读取。

账号级隔离、运行时会话管理与岗位目录共同处理用户及岗位的数据边界，持久化存储保存后续任务所需的数据。两者配合，为实例弹性运行和招聘上下文延续提供支持。

持久化数据的价值不止于恢复任务。HR 与智能体的每轮对话、筛选动作、采纳与拒绝反馈都能够留痕，连同运行日志和调用轨迹进入审计与分析链路。这些数据记录了用户如何表达需求、哪些推荐被接受，以及哪些功能尚未满足预期。

数据进一步支撑两类画像：HR 招聘画像刻画个人偏好与筛选风格，岗位或业务需求画像刻画具体职位的招聘要求。两类画像共同反哺匹配和推荐策略，使结果更贴近真实招聘意图，新的使用与反馈再持续回流。前程无忧给出的案例口径是，数据沉淀推动了 70% 的功能更新。

产品需求也可以直接出现在对话中。用户会向 Agent 表达功能不好用、某种要求无法满足，或期待新的能力。团队通过留痕数据与分析发现用户为什么不来、为什么不用、还需要哪些功能，再将这些反馈转化为产品迭代。相比仅从既定界面行为推测需求，对话增加了用户直接表达困惑与期望的渠道。

Agent Sandbox 在这条链路中承接运行与工作空间，持久化存储保留业务数据，SLS 与 MaxCompute 支持审计和分析，反馈再回到招聘功能与推荐策略。实践由此从功能验证推进到规模承载、成本治理，再连接到持续迭代。

先快速验证跑通，再规模上量扛住增长，最后稳定运营控住成本——每一步都让底座更成熟，也让 Agent 持续变强。