AI 把活干了，人类工程师该做什么？
10 天 37 组实验的 Agent 依然需要人类的灵感一击——这不是 Agent 的弱点，是人类价值的证明。
前言
一个推荐系统团队用 9 层 Multi-Agent 架构自主完成了生成式召回模型的研发。10 天，37 组实验，从基线 HitRate@100=0.2038 一路迭代到多路径融合。Agent 自己探索了 MoE 专家数量、层数、门控机制、激活函数、学习率、auxiliary loss 等多个维度，自主尝试、自主记录、自主优化。
但同样值得记录的是系统做不到的事：最关键的一次性能跳跃，来自一个人工输入的创新性 Idea——Target Aware Memory，为码本不同 decode 阶段配置差异化的 memory。回顾前三个阶段，系统自主完成的架构探索本质上都是在已有架构的参数空间内做网格搜索，而 Target Aware Memory 引入了一个全新的机制维度。
这恰好勾勒出当前人机协作的真实边界：Agent 擅长高效试错和知识积累，而真正跳出框架的灵感，仍然属于有想法的人类。
一、Agent 擅长试错，人类负责灵感
推荐系统召回模型的研发是一个典型的实验密集型工作。一次完整的实验周期包含方向调研、代码实现、配置生成、集群提交、结果分析、知识记录。单次执行需要数小时到一天，且每一步都埋着坑——em_id 和 item_id 混淆导致 hitrate 全零，CAST 用 INT 导致大商品 ID 溢出。这些踩坑经验散落在个人记忆中，换一个人很可能从头再踩一遍。
既然瓶颈在执行而非思考，一个自然的想法是：用 Agent 把执行层整体接管。
但单体 Agent 架构会撞上三堵墙：
上下文的物理天花板。 一次完整实验涉及模型代码、训练 biz 配置、集群日志、ODPS SQL、历史实验记忆等，单一上下文窗口无法容纳所有信息，压缩后又会丢失关键细节。
角色冲突。 写代码时需要关注维度对齐和异常防护的细节，做实验分析时需要高层次的指标对比和方向判断，两种思维模式放在同一个 Agent 中会互相干扰，质量两头打折。
失败耦合。 代码验证失败不应该污染实验提交逻辑，集群任务 OOM 不应该影响代码审查流程。单体架构下，一个环节的异常会连锁污染后续所有环节的上下文。
所以他们选择了分层的 Multi-Agent 架构：四层 Agent，9 个智能体，每个有明确的职责边界、输入输出契约和独立的失败处理策略。L1 知识与记忆层负责信息摄入和记忆管理；L2 任务编排层包含 Planner 有限状态机、Architect 代码生成、Reviewer 质量审查；L3 代码执行层有 Validator 三级门控、Training Biz Creator、Experiment Executor、Task Error Fixer；L4 实验反馈层负责信号回收和知识沉淀。
这套系统在 10 天内完成了 37 组实验的自主迭代。架构探索中大量实验结果为负——16 专家的 MoE 直接下降 19.7%，3 层 MoE 下降 13.0%。但也有正向发现：RMSNorm 带来加 2.7%。超参调优中发现了最优组合加 5.3%。验证环节拦截了约 60% 的模型代码 bug。
但最大的性能跳跃——Target Aware Memory——来自人工。这证明了一件事：Agent 擅长的是在给定方向上高效执行和迭代优化，而真正跳出既有框架的创新性 idea，仍然高度依赖人类研究者的洞察。
这和"2026 年人类工程师"文章里提到的"编排者"角色完全一致。编排者最值钱的工作是定义问题——Agent 可以在"怎么实现"上做到极致，但"实现什么"和"往哪个方向突破"仍然需要人类来定义。
二、从编码者到定义者——新分工
当 Agent 把执行层接管之后，所有角色都在升级。
Yoho.AI 的实践展示了一个完整的技术创业路径：产品、设计、开发、测试四个角色全面面向 AI Native 进行工作模式升级。
产品角色从写需求文档变成生产 Agent 自然语言到结构化 Spec 的自动转换。在 Aone 提交需求后，Yoho Server 自动触发 AI 流水线：结构化阶段通过 MCP 工具获取工单详情、评论、关联语雀文档；评审阶段用 7 维度雷达图评估需求质量；记忆召回三路并行；最终生成 OpenSpec 格式的技术设计文档。产出物是一份 AI 和人都能理解的、可验证的 spec。
设计角色从出设计稿变成设计稿到代码的 Skill 链路，MCP 对接设计系统。
开发角色从写代码变成 Harness 约束下的 AI 自主编码，C3 不变量保证质量底线。开发者启动 Harness 环境，AI Agent 进入约束执行模式——读取 spec 理解要做什么，召回项目知识，自动完成编码到编译到提交到安装到运行 E2E 测试。整个过程人不需要逐行指导。
测试角色从手动验证变成 dfxcli 加 WDA 自动化，AI 标定失败分类。
从需求到验证通过，核心交互只有两步：确认设计文档加确认测试结果。
AI 时代产品经理的"基本功"也在发生变化。不再是画原型、写 PRD、跟进排期，而是把模糊的业务需求转化为精确的技术规格，把人类的意图翻译成 AI 能理解的结构化规范。这是编排者的核心能力，越早训练越好。
三、用户意图不是状态，是过程
如果人类工程师的新角色是"定义者"，那他们需要理解一个更根本的问题：用户到底想要什么？
"用户意图"这四个字，可能是互联网产品领域被引用最多、却也被理解得最模糊的概念之一。在搜索引擎中，用户意图约等于查询词背后的真实需求。在推荐系统中，意图进一步泛化为用户行为序列背后的潜在偏好。在电商场景中，意图更常被窄化为"购物意图"。
但现实远比这复杂。一个用户打开淘宝，她的意图可能是"给即将生日的闺蜜挑个礼物，预算两百左右，要有点小心思但不要太正式"——这不是一个品类标签能概括的，它包含了社交关系、预算约束、情感调性、场景适配等多重维度。更重要的是，这个意图本身是流动的。
传统定义建立在三个失灵假设之上：
意图是离散可枚举的。 真实的意图往往是跨品类的（"布置一个温馨的阳台角落"涉及绿植、灯具、坐垫、收纳），甚至是非商品化的（"让自己看起来更有精神"）。
意图是用户主动表达的。 大量用户在消费早期阶段并不明确自己的需求，他们需要被"激发"而非被"匹配"。
意图是稳定的。 一次浏览 session 中用户的意图可能经历多次转变、分裂、甚至完全逆转。
大语言模型的出现改变了这一切——我们现在有了能够理解自然语言语义、追踪长程上下文、进行复杂推理的技术基础。问题不再是"能不能"，而是"要不要"以及"怎么做"。
新的意图引擎把意图定义为一个有生命周期的过程：萌芽、强化、稳定、衰退、消亡。三层意图供给从物理层到需求层再到偏好层，逐层细化。L0 物理层是用户长期稳定的属性；L1 需求层是元意图表达，包含品类、场景、受众及推断理由；L2 偏好层是细化偏好，包含品牌倾向、价格预算、决策状态及实时心理。
一个关键洞察是：对话不等于打字。气泡式追问、选择题而非填空题、从行为序列中推断"用户在犹豫什么"——本质上是系统单方面在做对话推理，用户感知到的只是"推得越来越准"。
四、信任与控制权
当我们拥有了强大的 AI Agent 能力后，一个根本性的设计哲学分歧浮出水面：我们是在为用户理解意图，还是在让 Agent 替用户决策？
OpenAI 在 ChatGPT 中推出了购物功能和 Agentic Commerce Protocol，与 Stripe 合作建立开放标准。Amazon 的 AI 购物助手 Rufus 据报道已驱动超过 120 亿美元销售额。Agent 替用户决策已经不是设想，而是已发生的事实。
但现实给出了有趣的反馈：OpenAI 后来关闭了 Instant Checkout 功能。原因是，当 Agent 直接替用户完成购买决策时，用户的信任和掌控感是脆弱的。
这恰好印证了两种立场在极端情况下的问题。纯粹的"以人为本"可能导致过度保守——明明系统已经高度确信用户需要什么，却还要反复确认。纯粹的"以 Agent 为本"则可能导致 Filter Bubble 的深化——用户被困在系统认为的"你是谁"的牢笼里。
答案是在不同的决策阶段和确信度下，动态调整人机协作的比例。当系统对意图的判断高度确信时，可以偏向 Agent 主导；当意图模糊或涉及高决策成本时，应该偏向人的主导。
用户对 AI 系统的信任建立在两个基础上：一是系统的能力，二是系统的透明度。缺少透明度的高能力系统反而会引发更强的不信任。真正的以人为本，包含了让人保持知情权和控制权。
这也和"铁律"文章中讨论的安全层是一致的——安全不只是技术问题，也是信任设计问题。
五、新人的阶梯
这是 2026 年最焦虑的问题之一：如果 day 1 AI 已经在写代码了，新人该怎么成长？
传统的成长路径很清楚：写简单代码，写复杂代码，设计系统，定战略。但在 AI 时代，第一级阶梯被踩掉了。
那新人从哪里起步？
第一条：从审查开始。 不让新人写代码，让新人审 AI 的代码。通过"看-理解-判断-反馈"的循环，培养技术直觉。优势是新人一开始接触的就是完整的生产代码。风险是如果审查标准不够清晰，新人可能变成 approve 按钮而没有真正学到东西。
第二条：从定义问题开始。 让新人先学会写需求、拆任务、定约束，然后再让 AI 实现。训练的是"想得清"的能力——把模糊的业务需求转化为精确的技术规格。这是编排者的核心能力，越早训练越好。
第三条：从调试开始。 不写新代码，而是修 bug。AI 生成的代码出了问题，新人需要理解代码、定位问题、修复验证。训练"理解他人代码"的能力——这恰好是传统编程教育中最薄弱的环节。
这三条路径不是互斥的，可以组合使用。关键是：新人需要一个新的成长阶梯，而不是旧的阶梯被砍掉一级。
10 天 37 组实验的 Agent 案例为这三条路径提供了一个生动的注脚：Agent 完成了执行层的所有工作（写代码、配环境、跑实验、分析结果），但人类研究者依然在定义问题（决定探索哪个方向）、审查结果（判断实验是否有效）、调试异常（当集群任务 OOM 时介入）。新人的成长路径，恰恰就是在这三个维度上逐渐升级——从"能看懂 Agent 做了什么"到"能判断 Agent 做得好不好"到"能告诉 Agent 该做什么"。
结语
AI 把活干了——执行层的活。代码实现、配置生成、集群提交、结果分析，这些工作 Agent 确实干得又快又好。
但人类工程师该做什么？做 Agent 做不了的事。做那些需要创新性 idea 的事。做那些需要把模糊的业务需求转化为精确技术规格的事。做那些需要理解用户真实意图的事。做那些需要在 Agent 出错时兜底的事。做那些需要判断方向对不对的事。
那个让推荐模型性能实现最大跳跃的 Target Aware Memory，不是 Agent 自己探索出来的，是人类研究者灵光一现的 idea。但这不意味着 Agent 白干了——恰恰是 Agent 在 37 组实验中积累的知识和记忆，为这个 idea 提供了验证和落地的土壤。
Agent 做执行，人类做定义。Agent 负责试错，人类负责灵感。这不是人类价值的削弱，是人类价值的重新聚焦。
代码是 Agent 的事了。但往哪个方向走、走得对不对、出了事谁负责、用户真正想要什么——这些还是人类的事。