当前位置：首页 > news >正文

26 分钟不谈 GPU：Agent 时代的核心竞争力，藏在 Harness 工程里

news 2026/7/17 16:29:28

【摘要】围绕黄仁勋最新访谈提出的 Agent 工程方向，结合 LangChain 与英伟达的实测数据，拆解 Harness 架构的核心组成、工程价值与落地方法，分析成本下降对开发范式的影响，梳理生产环境的安全治理方案，为技术团队从代码开发转向 Agent 构建提供完整参考框架。

引言

过去两年，行业对 AI 能力的讨论始终围绕模型参数、算力规模与基准榜单展开。多数团队遇到 Agent 效果不达预期时，第一反应是更换更大的模型、采购更多算力。直到 LangChain 公开一组实测数据：底层模型未做任何权重调整，仅优化系统提示、工具描述与中间件层，Deep Agents 评测分数从低位追至 0.86，与榜首闭源模型仅差 0.01，单次任务成本却从 43.48 美元降至 4.48 美元，降幅接近十倍。

这组数据指向一个正在发生的行业转向：Agent 系统的能力上限，不再只由模型本身决定，包裹在模型外围的整套工程系统，正在成为拉开企业差距的核心变量。黄仁勋在与 LangChain 创始人的 26 分钟对谈中，全程未提及 GPU、算力或新模型参数，核心议题始终围绕工程师应如何从 “写代码” 转向 “构建 Agent 系统”。

本文面向技术负责人、架构师与 AI 应用开发团队，系统梳理 Harness 工程的定义、架构与落地方法，结合生产环境的安全治理实践，给出从 Demo 到规模化落地的实施路径，帮助团队在模型同质化的阶段，建立可持续的工程竞争优势。

一、从模型竞赛到系统竞赛：Agent 能力的第二增长曲线

1.1 被低估的模型外围：0.01 分差距背后的 10 倍成本差

在传统认知里，大模型的能力曲线与参数规模、训练数据量强相关。提升 Agent 任务完成率的主流路径，一直是升级更强的基础模型。LangChain 与英伟达的联合测试打破了这一惯性认知，整个优化过程未触及 Nemotron 3 Ultra 的模型权重，全部工作集中在模型外围的 Harness 层。

测试基于 Deep Agents 评测基准展开，优化前的原始模型配置对应 43.48 美元的单次任务成本，优化后成本降至 4.48 美元，同时评测分数提升至 0.86，与最高分 0.87 仅差 0.01。这意味着同等模型能力下，工程系统的优劣可以带来近十倍的成本差异，以及接近闭源顶尖模型的任务完成效果。

这种差异的本质，是模型单次推理能力与长链路任务完成能力的区别。基础模型擅长单步推理、代码生成与信息整合，但真实业务任务往往包含多轮工具调用、异常重试、上下文切换与结果校验，这些环节的执行质量，完全由模型之外的系统决定。就像同一台发动机，装在不同的底盘与传动系统上，最终的动力输出、可靠性与油耗会呈现量级差异。

很多团队在 Agent 开发中存在一个常见误区：把大量时间花在调试单轮 Prompt 效果上，却忽略了任务重试、状态恢复、工具参数校验等外围机制。实际生产环境里，80% 以上的任务失败并非模型推理错误，而是工具调用格式异常、上下文溢出、失败后无降级策略这类工程问题。Harness 工程解决的，正是这部分被模型榜单掩盖的真实痛点。

1.2 Harness 的定义与边界：它和 Agent 框架有什么不同

Harness 一词源自软件工程中的测试 harness 概念，原指为被测程序提供运行环境、输入输出控制与结果校验的整套装置。在 Agent 系统中，Harness 是包裹在模型之外，负责指令组织、工具调度、状态管理、安全隔离与结果验证的完整工程层。它不改变模型本身的推理能力，而是通过系统性的约束与引导，将模型的单次推理能力转化为稳定、可重复的任务执行能力。

行业内经常将 Harness 与 Agent 框架混淆，两者实际处于不同的技术层级，核心职责存在明确区分：

技术层级	核心定位	典型代表	解决的核心问题
基础模型	提供推理与生成能力	Nemotron 3 Ultra、GPT 系列、Claude 系列	理解语义、生成代码、逻辑推理
Agent 框架	定义 Agent 的逻辑结构、工具接线与循环流程	LangChain、LangGraph、AutoGen	快速搭建 Agent 的基础运行逻辑
Agent Harness	生产级运行管控、质量保障与安全治理	LangChain Deep Agents、NemoClaw	让 Agent 在生产环境稳定、安全、可观测地运行

简单来说，Agent 框架解决的是 “能不能跑起来” 的问题，Harness 解决的是 “能不能稳定跑在生产环境、能不能控住成本、能不能守住安全边界” 的问题。多数开源框架默认提供了基础的 Agent 循环，但缺少完整的评测体系、权限治理、异常熔断与成本管控能力，这些正是 Harness 层需要补充的内容。

Harness 工程也不等同于 Prompt 工程。Prompt 工程只是 Harness 众多组件中的一项，完整的 Harness 还包含工具接口定义、记忆管理、任务拆分策略、重试机制、沙箱运行环境、评测断言、审计日志等十几个核心模块。Prompt 优化带来的通常是单点能力提升，Harness 优化带来的是整个系统的可靠性、成本与安全的全面改善。

1.3 Deep Agents 评测：衡量真实工作能力的新标尺

过去评估模型能力，主流基准集中在单轮问答、代码生成、知识记忆等维度，比如 HumanEval、MMLU 等。这类基准可以反映模型的基础推理水平，却无法衡量 Agent 在多步骤、带工具、可纠错的真实任务中的表现。Deep Agents 评测基准的出现，填补了这一空白。

Deep Agents 评测面向复杂多步任务场景，覆盖任务规划、工具调用、错误修复、结果验证等完整 Agent 执行链路。它的评分标准不是单轮输出的语义相似度，而是任务最终是否达成预期目标，比如代码是否通过测试、数据是否正确写入、报表是否符合格式要求。这种以结果为导向的评测，更贴近企业真实业务的验收标准。

这类评测基准的普及，也让 Harness 的价值变得可量化。在传统单轮基准上，不同模型的分数差距一目了然，外围工程很难带来量级提升。但在面向真实任务的 Agent 评测中，Harness 的优化空间远大于模型本身的参数升级。LangChain 的测试数据已经验证，通过系统层优化，开源模型可以追平顶尖闭源模型的任务完成率，同时成本大幅降低。

这里需要注意一个常见误区：很多团队用人工主观感受评估 Agent 效果，没有建立标准化的评测集。这种方式无法支撑持续迭代，每次 Prompt 或工具调整后，都难以量化判断效果是变好还是变差。建立与业务目标对齐的评测集，是 Harness 工程的第一步，也是所有优化的前提。

二、Harness 工程的七层架构：把模型能力转化为稳定生产力

完整的 Agent Harness 体系可以划分为七个逻辑层级，从内到外依次覆盖指令上下文、工具接口、任务编排、执行运行、验证验收、可观测性与治理。每个层级承担独立职责，共同构成闭环的 Agent 运行系统。

注：基础模型层不属于 Harness 范畴，是整个系统的能力底座。

2.1 指令上下文层：Prompt、工具描述与记忆管理

指令上下文层是 Harness 最贴近模型的一层，也是最容易被感知的部分。它包含系统 Prompt、工具功能描述、上下文窗口管理与短期记忆机制，核心作用是把业务目标翻译成模型能够准确理解的指令与上下文。

很多团队对这一层的认知停留在 “写好 Prompt”，实际工程细节远不止于此。系统 Prompt 不仅要定义 Agent 的角色与目标，还要明确输出格式约束、错误处理原则、边界条件与终止条件。工具描述的质量直接决定模型调用工具的准确率，描述模糊、参数定义不清晰，会导致大量工具调用格式错误或参数遗漏。

上下文管理是这一层的核心难点。长链路任务会产生大量中间结果、工具返回值与历史对话，很容易撑满上下文窗口。常见的处理策略包括分层摘要、关键信息持久化、非必要上下文压缩。合理的上下文管理可以在不损失关键信息的前提下，将单次推理的 token 消耗降低 30% 以上，这也是成本优化的重要来源。

记忆管理分为短期记忆与长期记忆。短期记忆对应单次任务内的执行轨迹，长期记忆对应跨任务的知识与历史经验。工程实现上，短期记忆通常保存在任务状态中，长期记忆则通过向量数据库或结构化知识库承载。需要注意的是，不是记忆越多越好，无关信息会干扰模型判断，引入记忆的同时必须配套检索精度控制与信息过滤机制。

2.2 工具接口层：标准化接入与调用管控

工具是 Agent 连接现实世界的接口，也是 Harness 工程中承上启下的关键层。工具接口层负责所有外部能力的标准化接入、参数校验、错误处理与调用统计，让模型以统一的方式调用不同类型的外部系统。

工具接入的标准化程度，直接影响 Agent 的扩展效率。成熟的 Harness 会提供统一的工具注册协议，包含功能描述、参数 schema、错误码定义、超时配置与权限标签。新工具只需要按照协议完成适配，就可以被所有 Agent 实例复用，不需要重复开发对接逻辑。

调用管控是这一层容易被忽略的部分。模型调用工具存在典型的失效模式：重复调用同一工具、调用无关工具、参数缺失或格式错误、忽略工具返回的错误信息。Harness 需要在工具调用前后增加拦截逻辑，比如参数合法性校验、重复调用检测、错误自动重试、调用频率限制。LangChain 在优化中发现，移除 80% 的非必要工具，只保留核心能力，反而能让 Agent 执行速度更快、准确率更高。

工具层还有一个常见的工程误区：直接把内部系统的原始 API 暴露给 Agent。这类 API 通常参数复杂、依赖多、缺少错误说明，模型很难正确调用。更合理的做法是对内部 API 做一层 Agent 专属封装，简化参数、补充自然语言描述、统一返回格式，降低模型的调用门槛。

2.3 任务编排层：拆分、重试与状态持久化

任务编排层是 Harness 的调度中枢，负责将用户的原始目标拆解为可执行的子任务，管理执行流程，处理异常情况，维护任务状态。它决定了 Agent 处理复杂任务的上限，也是区分简单聊天机器人与生产级 Agent 的核心标志。

任务拆分是编排层的核心能力。对于多步骤复杂任务，模型需要先规划执行路径，再逐步执行。常见的拆分策略包括线性分步、并行分支、子 Agent 委派。不同任务适合不同的拆分方式，结构化强的流程适合预定义 DAG，边界模糊的探索型任务适合动态规划。工程实践中，通常采用 “规划 - 执行 - 复盘” 的多轮循环，每执行几步就重新评估进度，调整后续计划。

重试与降级策略直接决定系统的鲁棒性。工具调用超时、第三方服务异常、模型推理失败都是生产环境的常态。成熟的 Harness 会针对不同失败类型配置不同的重试策略：网络类错误指数退避重试，参数类错误修正后重试，逻辑类错误更换路径重试。对于无法恢复的失败，需要有明确的降级机制，比如中断任务并通知人工介入，而不是无限循环消耗算力。

状态持久化是长任务的基础保障。执行时间超过几分钟的任务，随时可能遇到进程重启、服务升级、节点故障。如果任务状态只保存在内存中，中断后就需要从头开始，造成大量算力浪费。Harness 需要将任务的执行进度、中间结果、已调用工具记录持久化存储，支持断点续跑，从失败的位置继续执行，而不是全量重试。

2.4 执行运行层：沙箱环境与权限注入

执行运行层是 Agent 动作的实际执行环境，负责承载代码运行、工具执行与文件操作，同时施加安全隔离与权限约束。这一层是生产安全的第一道防线，也是企业级 Agent 与 Demo 的核心区别。

沙箱是执行层的核心组件。Agent 生成的代码、执行的系统命令、访问的文件系统，都必须限制在沙箱范围内，避免污染宿主环境或越权访问敏感数据。OpenShell 这类运行时采用内核级隔离技术，结合 Linux 命名空间、seccomp-BPF 过滤器与自定义 eBPF 程序，为每个任务创建独立的执行环境，即使 Agent 逻辑被攻破，也无法突破沙箱边界。

权限注入是执行层的关键设计原则。Agent 不应直接持有长期有效的访问密钥，更合理的方式是由运行时根据当前任务的权限范围，临时注入访问凭证。任务结束后凭证自动失效，Agent 无法留存或复用。这种设计可以最大程度降低密钥泄露的风险，也符合最小权限的安全原则。

执行层还需要处理运行时的资源限制，包括 CPU 配额、内存上限、执行时长、磁盘空间占用。没有资源限制的 Agent 可能因为死循环、大文件生成耗尽系统资源，影响其他服务。生产环境中，每个沙箱实例都需要配置独立的资源配额，超出阈值自动终止并告警。

2.5 验证验收层：评测断言与回归体系

验证验收层负责判断 Agent 的输出是否符合预期，是质量保障的核心环节。它包含单任务的结果断言，以及持续迭代的回归评测体系。

很多团队的 Agent 开发缺少验收标准，依赖人工肉眼判断结果好坏。这种方式无法支撑规模化迭代，也很难发现隐性问题。成熟的做法是为每类业务任务定义可自动化执行的验收断言，比如代码任务运行单元测试、数据任务校验结果行数与关键指标、文档任务检查格式与关键信息点。断言越具体、越可自动化，Agent 的质量就越可控。

回归评测体系是持续优化的基础。每次调整 Prompt、工具或编排策略后，都需要在固定评测集上跑全量测试，观察总分变化与单项指标波动。没有回归体系，优化就变成了黑盒操作，可能解决了一个问题，又引入了三个新问题。LangChain 能够快速迭代 Harness 效果，核心前提就是拥有完整的 Deep Agents 评测基准，可以快速量化每次调整的收益。

验收层还有一个重要作用：识别 “自信的错误”。大模型经常以非常确定的语气输出错误结果，如果只看自然语言回复，很容易误判为任务完成。验证层必须基于外部客观证据判断结果，比如测试是否通过、数据库记录是否存在、文件是否生成，而不是相信 Agent 的文字表述。

2.6 可观测层：轨迹追踪与成本度量

可观测层负责完整记录 Agent 的执行过程，支撑问题排查、性能优化与成本分析。对生产级 Agent 来说，执行轨迹和传统软件的日志一样重要。

完整的执行轨迹应该包含每一轮模型的输入输出、每一次工具调用的请求与返回、每一步的状态变更、耗时与 token 消耗。出现任务失败时，可以通过轨迹快速定位问题出在规划阶段、工具调用阶段还是结果验证阶段，而不是从头复现排查。轨迹数据还可以沉淀为新的评测用例，把每一次偶然失败都变成后续的回归测试点。

成本度量是可观测层容易被忽略的能力。Agent 任务的成本构成复杂，包含模型推理费用、工具调用费用、计算资源费用。不同的 Prompt 策略、重试次数、模型选型，都会带来成本的显著差异。Harness 需要提供细粒度的成本统计，按任务、按 Agent、按工具维度拆解成本，帮助团队找到优化空间。

2.7 治理层：权限、合规与组织管控

治理层是 Harness 的最外层，面向企业管理需求，包含身份权限、合规审计、成本管控与组织级的资源分配。它不直接参与单任务的执行，却决定了整个 Agent 体系能不能在企业内规模化推广。

身份治理的核心是明确 Agent 的身份属性。Agent 以谁的名义执行操作、拥有哪些资源的访问权限、操作由谁负责，这些都是必须回答的问题。行业内的常见做法是为 Agent 分配独立的虚拟身份，遵循企业统一的 RBAC 权限模型，操作记录与人类员工一样纳入审计体系。

合规审计要求所有 Agent 操作可追溯、可回放。对于金融、医疗这类强监管行业，Agent 的每一步操作都需要留下完整日志，支持事后审计与问题回溯。治理层需要统一管理审计策略，确保不同业务线的 Agent 都满足合规要求。

成本治理负责全公司的 Agent 算力预算分配、用量监控与异常告警。当 Agent 大规模应用后，算力费用很容易失控。治理层需要设置部门级的成本配额，提供用量看板，对异常消耗自动告警，避免单个任务故障产生天价账单。

三、成本下降 10 倍带来的开发范式变革

Harness 优化带来的不只是账单数字的减少，更是整个 Agent 开发方法论的转变。当单次任务成本从几十美元降到几美元，很多过去不可行的开发方式变成了主流，团队的工作重心也会随之迁移。

3.1 从 “少测慎改” 到 “高频迭代”：评测驱动的开发模式

在单次评测成本高昂的阶段，团队普遍倾向于 “少测慎改”。每次调整 Prompt 或工具配置，都要反复斟酌才敢上线测试，因为一次全量评测可能花费数百甚至数千美元。这种模式下，迭代速度很慢，很多优化想法因为测试成本太高无法验证。

成本下降一个数量级后，开发模式会转向评测驱动的高频迭代。团队可以同时测试多组 Prompt、多种工具配置、不同的重试策略，通过并行评测快速找到最优解。评测可以嵌入日常开发流程，每次代码提交自动触发回归测试，就像传统软件的单元测试一样。

成本下降还会带来 “探索式优化” 的普及。过去团队只会针对已知问题做定向优化，现在可以尝试更多创新性的架构调整，比如新增子 Agent、引入不同的规划策略、测试新的工具组合。即使一半的尝试没有效果，整体成本也在可接受范围内。

这里存在一个常见的认知误区：很多团队认为成本优化只是运维层面的事，和开发团队无关。实际上，成本结构的改变会直接影响开发效率与创新空间。当实验成本足够低，团队的试错意愿会显著提升，最终的产品迭代速度也会拉开差距。

3.2 模型选型的新逻辑：前沿探路 + 专用收敛的分层策略

过去企业选择模型，通常倾向于一步到位，用能力最强的模型支撑所有场景。这种方式的问题是成本高昂，大量简单任务也在消耗高端模型的算力。Harness 技术成熟后，模型选型出现了更精细化的分层策略。

第一种策略是 “前沿模型探路，专用方案收敛”。新业务场景刚出现时，任务边界不清晰，验收标准也不明确，适合用能力最强的前沿模型快速探索可行性，验证业务价值。当任务流程稳定、验收标准清晰后，再通过 Harness 优化，将任务迁移到成本更低的开源模型或中小模型上。LangChain 的测试已经证明，经过充分的 Harness 调优，开源模型可以在特定任务上接近顶尖闭源模型的效果。

第二种策略是 “推理强度分层”。同一个任务的不同阶段，对模型能力的要求不同。规划阶段需要强推理能力来拆解任务、设计路径，验证阶段需要严谨的判断能力来检查结果，执行阶段的工具调用则不需要太高的模型能力。行业内称为 “推理三明治” 策略：规划和验证用高强度模型，执行阶段用低一档的模型，全程使用最高强度模型反而会增加延迟与成本，收益却很有限。

第三种策略是 “按价值匹配模型”。高价值、低频次的复杂任务，使用高端模型保障成功率；高频次、标准化的简单任务，使用低成本模型控制开销。Harness 层可以统一封装模型路由逻辑，业务层不需要关心底层用的是哪个模型，只需要定义任务的优先级与成本约束。

3.3 企业 Agent 资产的沉淀路径：从一次性 Prompt 到可复用工程体系

很多企业的 Agent 开发还停留在 “一案一策” 的阶段，每个业务场景单独写 Prompt、单独接工具、单独调试。这种模式下，每个项目的经验都无法复用，团队规模扩大后，开发效率不会提升，反而会因为重复建设越来越慢。

Harness 工程体系化后，企业的 Agent 资产会逐步沉淀，形成可复用的公共能力。沉淀通常沿着三个方向展开：

第一是公共组件沉淀。通用的工具封装、Prompt 模板、重试策略、评测断言、沙箱配置，都可以沉淀为公共组件，供不同业务线直接复用。新场景开发时，不需要从零搭建，只需要基于公共组件做少量业务定制。

第二是业务领域资产沉淀。特定行业的术语体系、业务规则、工具接口、验收标准，会逐步形成领域专属的 Harness 配置。这些资产和企业自身的业务深度绑定，是外部模型厂商无法提供的，也是企业长期的竞争壁垒。

第三是轨迹与评测数据沉淀。每一次任务执行的轨迹、成功案例、失败案例，都会持续补充到评测集中。评测集越丰富，Agent 的优化就越精准，质量也越稳定。这些数据积累得越久，迁移成本就越高，后来者越难追赶。

真正的企业 Agent 护城河，不是用了什么模型，而是沉淀下来的工具说明、业务词汇、权限边界、历史轨迹和验收数据。这些东西共同决定了 Agent 是不是真的理解这家公司的业务，能不能稳定地完成具体工作。

四、生产落地的安全底线：Agent 不能直接拿到密钥

Agent 从聊天窗口走向生产环境，最核心的门槛不是能力够不够强，而是风险能不能控住。一个能调用内部 API、操作数据库、执行系统命令的 Agent，一旦失控造成的损失远大于普通软件漏洞。黄仁勋在访谈中明确强调，Agent 不应直接持有长期密钥，权限管控必须作为系统设计的核心原则。

4.1 NemoClaw 蓝图的安全分层：OpenShell 沙箱的实现原理

英伟达推出的 NemoClaw 蓝图，是生产级 Agent 安全架构的典型参考。它采用分层防御设计，从下到上依次是硬件与宿主系统、OpenShell 运行时、策略引擎、隐私路由与 Agent 应用，每一层承担独立的安全职责，形成纵深防御体系。

OpenShell 运行时是整个安全体系的基础。它不同于普通的容器隔离，而是采用更轻量的内核级隔离技术，为每个 Agent 任务创建独立的执行环境。文件系统层面，Agent 只能访问授权的目录与文件，无法读取宿主系统的敏感数据。网络层面，默认采用拒绝所有出站请求的策略，只允许访问预先审批的外部服务地址。进程层面，通过 seccomp-BPF 限制系统调用范围，禁止高危操作。

NemoClaw 蓝图的核心设计理念是 “默认不安全，显式授权”。Agent 默认没有任何权限，所有能力都需要通过策略显式授予，权限范围严格匹配任务需求。这种设计和传统软件 “默认开放，逐步限制” 的思路完全相反，更适合 Agent 这种行为不可完全预测的系统。

4.2 权限治理的四个核心问题

落地 Agent 权限体系，必须回答四个基础问题，任何一个问题缺失明确答案，都意味着存在安全风险。

第一个问题：Agent 以谁的身份行动。Agent 的所有操作都需要关联明确的责任主体。常见的身份模型有三种：代理用户身份，即 Agent 代表当前操作的用户执行动作，权限和用户本人一致；独立虚拟身份，即为 Agent 分配专属账号，权限单独配置；角色身份，即 Agent 对应某个岗位角色，继承角色的权限集合。三种模式适用于不同场景，代理身份适合个人助理类场景，虚拟身份适合自动化任务，角色身份适合跨部门的公共服务 Agent。

第二个问题：哪些命令可以执行。不是所有系统命令、API 接口都对 Agent 开放。需要建立分级的命令白名单，低风险操作自动放行，中风险操作增加校验，高风险操作必须人工审批。判定风险等级的维度包括操作破坏性、影响范围、数据敏感度、不可逆程度。比如查询类操作风险低，删除类操作风险高；只读 API 风险低，写入 API 风险高。

第三个问题：失败后如何停止与回滚。Agent 执行过程中出现异常，不能放任继续运行，必须有明确的终止机制。对于已经产生副作用的操作，需要有对应的回滚方案，比如数据库操作配套事务、文件操作配套备份、配置变更配套回滚脚本。高风险操作执行前，必须先验证回滚机制可用。

第四个问题：谁能复盘完整轨迹。所有 Agent 操作必须留下完整的审计日志，包含执行时间、操作内容、访问资源、输出结果、关联身份。日志需要独立存储，Agent 本身无权修改或删除。出现安全事件时，可以通过轨迹完整回放整个执行过程，定位问题根源，界定责任边界。

4.3 常见安全误区与规避方案

Agent 安全落地过程中存在很多典型误区，很多团队踩过同类的坑。梳理常见误区与对应方案，可以帮助团队少走弯路。

第一个误区：把密钥直接放在环境变量里交给 Agent。这是最危险也最常见的错误。Agent 一旦拿到长期有效密钥，就可以不受限制地访问对应资源，即使沙箱隔离也无法限制。正确的做法是通过运行时临时注入凭证，凭证有效期和任务生命周期绑定，任务结束自动失效。

第二个误区：依赖 Prompt 约束 Agent 的行为。很多团队试图通过系统提示词告诉 Agent “不要执行危险操作”，这种方式完全不可靠。大模型存在提示词注入风险，恶意用户可以通过构造输入绕过 Prompt 约束。安全规则必须在系统层面强制实施，不能依赖模型自觉遵守。

第三个误区：沙箱只隔离代码，不隔离网络。很多团队的沙箱只限制了本地文件系统，却没有限制网络访问。Agent 可以通过网络外发数据、调用未授权服务，同样会造成数据泄露。完整的沙箱必须同时覆盖文件、进程、网络三个维度。

第四个误区：没有人工审批机制。有人认为 Agent 自动化就是全程不需要人参与，实际上高风险操作必须保留人工审批节点。比如删除数据、修改生产配置、批量发送通知这类操作，Agent 可以生成执行方案，但最终执行需要人工确认。人工审批不是倒退，而是自动化与风险控制的平衡。

五、程序员的职责迁移：从写代码到造 Agent

黄仁勋在访谈中提出，程序员的工作重心正在从写代码转向构建 Agent。这不是说代码会消失，而是工作的价值重心发生了迁移。就像打字机普及后，写作的核心不再是打字速度，而是内容本身。代码能力依然重要，但不再是软件开发的全部价值。

5.1 工作清单的重排：哪些工作会被 Agent 承接

软件研发的工作可以粗略分为两类：一类是结构化、重复性、有明确规则的工作，另一类是定义性、设计性、需要判断权衡的工作。Agent 最先承接的，是第一类工作。

具体到日常开发场景，样板代码生成、格式转换、简单 Bug 修复、日志分析、文档初稿编写、常规测试用例生成这类工作，会越来越多地交给 Agent 完成。这类工作有明确的输入输出标准，容易通过评测验证效果，也是 Agent 性价比最高的应用场景。

工程师的工作重心会向更高价值的环节迁移。任务定义与边界梳理、系统架构设计、评测体系构建、权限治理设计、异常处理策略、复杂问题排查，这些需要深度思考与经验判断的工作，会变得比以往更重要。

这种变化不是岗位的消失，而是职责的升级。过去工程师需要亲手完成每一行代码，未来工程师需要设计一套能持续完成任务的 Agent 系统，定义它的目标、边界、规则与验收标准。就像工业革命后，工人从亲手生产产品，变成操作和维护生产设备。

需要客观看待的是，这种迁移不会让所有人同步受益。能不能跨过职责的转变，取决于个人能不能建立新的能力栈。只会写固定代码、不理解系统设计与业务逻辑的工程师，会最先感受到压力。

5.2 新一代工程师的核心能力

Agent 时代的软件工程师，需要在原有技术能力的基础上，补充几项新的核心能力。

第一项是评测构建能力。Agent 开发和传统软件开发最大的区别，是验收标准从明确的功能需求，变成了模糊的任务目标。能不能把业务目标拆解成可量化、可自动化的评测用例，直接决定了 Agent 能不能持续优化。好的评测体系，需要既覆盖正常场景，也覆盖边界情况与异常场景，既能衡量成功率，也能衡量效率与成本。

第二项是系统设计能力。Agent 系统不是单一的程序，而是包含模型、工具、编排、沙箱、评测多个组件的复杂系统。工程师需要理解每个组件的职责与边界，设计合理的交互流程与异常处理机制。传统后端开发的分布式系统设计经验，很多可以迁移到 Agent 系统设计中，但也需要补充 Agent 专属的设计原则。

第三项是安全治理能力。Agent 拥有行动能力后，安全就不再是安全团队单独的事。开发 Agent 的工程师必须理解权限模型、沙箱原理、审计要求，在设计阶段就把安全约束考虑进去。不懂安全的 Agent 开发者，构建的系统能力越强，潜在风险越大。

第四项是成本优化意识。Agent 的运行成本是持续发生的，不合理的设计会带来长期的算力浪费。工程师需要理解不同策略对成本的影响，在效果与成本之间做合理权衡。比如上下文如何管理、重试次数如何设置、模型如何路由，都需要兼顾效果与成本。

5.3 组织层面的适配

Agent 转型不只是个人能力的升级，也需要组织模式的相应调整。传统的功能团队模式，不一定适合 Agent 时代的研发节奏。

首先是团队职责的重新划分。过去按前端、后端、测试划分的职能团队，会逐步向按业务域划分的全栈团队转型。Agent 开发需要同时处理业务逻辑、工具对接、评测设计、安全配置，跨职能协作的成本很高，小而全的团队效率更高。

其次是质量保障体系的升级。传统的测试流程是针对确定性软件设计的，无法直接套用到 Agent 系统。QA 团队的工作重心会从写测试用例，转向构建评测体系、设计验收标准、监控线上质量。测试的对象从代码变成了整个 Agent 系统。

最后是运维体系的延伸。Agent 系统的运维和传统应用有很大不同，除了常规的服务可用性监控，还要增加任务成功率监控、成本监控、安全异常监控、轨迹日志管理。运维团队需要掌握 Agent 专属的排障方法，能够通过执行轨迹快速定位问题。

六、企业 Agent 栈的实施路径：从 Demo 到生产的落地步骤

很多企业在 Agent 落地时容易陷入两个极端：要么停留在 Demo 阶段，始终无法走向生产；要么一开始就追求大而全的架构，投入巨大却迟迟看不到效果。合理的实施路径应该分阶段推进，每个阶段都有明确的目标与产出，逐步迭代升级。

6.1 阶段一：用真实业务任务建立评测基准

很多团队第一步就急于搭建技术框架、接入各种模型，最后做出来的 Agent 不知道怎么衡量好坏，也不知道有没有业务价值。正确的第一步，是先不碰技术，从业务场景里筛选出适合 Agent 的任务，建立对应的评测基准。

筛选任务有几个标准：任务有明确的验收标准，能够客观判断完成与否；任务有一定的重复频率，值得投入自动化；任务的步骤相对清晰，边界不会无限扩张。满足这几个条件的任务，Agent 落地的成功率高，也容易量化收益。

确定任务后，需要整理一批典型的测试用例，覆盖正常场景、边界场景与异常场景。每个用例都要有明确的预期结果，以及对应的自动化校验方法。初期评测集不用追求大而全，覆盖核心场景即可，后续可以逐步补充。

这个阶段最容易犯的错误是用主观评价代替客观评测。“看起来不错”“大概能用” 这类判断无法支撑后续迭代，必须有可量化、可重复的评分标准。

6.2 阶段二：搭建模型 + Harness 的最小可用闭环

有了评测基准之后，就可以进入技术搭建阶段。这个阶段的目标不是做完美的系统，而是快速跑通从任务输入到结果输出的完整链路，验证技术可行性。

最小闭环需要包含几个核心组件：基础模型接入、核心工具封装、基础的 Agent 编排逻辑、结果校验脚本。不需要复杂的沙箱、完善的权限体系、华丽的前端界面，只要能在命令行里跑通完整任务，并且能自动评测打分即可。

这个阶段的重点是快速迭代 Harness 配置，通过评测反馈持续优化 Prompt、工具描述与编排策略。目标是在选定的任务上，达到可以接受的成功率与成本水平。很多团队在这里过早关注非核心功能，比如界面美化、多模型支持，反而拖慢了核心能力的验证节奏。

验证通过的标准很明确：在评测集上达到预设的成功率阈值，单次任务成本在可接受范围内。达到这个标准，就说明这个场景具备落地价值，可以进入下一阶段。

6.3 阶段三：补足沙箱、身份、日志与人工接管机制

验证完业务价值后，就进入生产就绪阶段。这个阶段的核心是补全安全与管控能力，让 Agent 可以真正接入真实的业务环境，而不是只在测试环境里运行。

需要补齐的核心能力包括四个方面。第一是沙箱执行环境，所有代码运行、工具调用都必须在沙箱中进行，隔离宿主资源。第二是身份与权限体系，为 Agent 分配独立身份，配置最小必要权限，建立审批流程。第三是日志与轨迹系统，完整记录执行过程，支持审计与排障。第四是人工接管机制，高风险操作需要人工确认，异常情况可以人工介入终止或修正。

这个阶段是很多项目的瓶颈期。Demo 阶段可以忽略的安全、合规、运维问题，到了生产环境都必须一一解决。很多团队因为低估这部分工作量，导致项目迟迟无法上线。实际上，这些能力是生产级 Agent 的必要组成部分，没有捷径可走。