先说结论：FDE 的瓶颈在上下文处理，用 Agent 放大
FDE（Forward Deployed Engineer，前向部署工程师）最先撞上的墙是上下文处理能力：一次分析可能要先上传约 150 页材料，通用模型却给出冗长且抓错重点的回答。2026 年 6 月 30 日 AI Engineer World’s Fair FDE 议程上，几家公司的方案收敛为一句话：用 Agent 放大 FDE——先自动化工作流两端（资料整理与依据明确规范的实现），把范围判断和客户责任留给人。Varick 工程负责人 JD 据此设计了三阶段 FDE Agent；Ramp 工程总监 Leo Mehr 的请求 Agent 估算节省约 20% scoping 时间（内部估算）；Factory 观察到的当前自主程度约 15% 到 20%（项目经验与估计）。岗位定义见《FDE 是什么岗位》。
Varick 的三阶段 FDE Agent：参与、工作流、自主维护
三个阶段各有分工：参与助手解决“知道什么”，工作流助手解决“搭得对”，自主维护助手解决“自己改”——演讲时前两个已运行。
| 阶段 | 做什么 | 核心难点 | 演讲时状态 |
|---|---|---|---|
| 参与助手 | 读会议笔记、文档、消息，回答“这个流程谁负责”“两种拼写是否同一人” | 实体与时间对应，高于一般企业搜索 | 已运行 |
| 工作流助手 | 嵌入平台，搭流程时提醒遗漏的边缘情况和依赖 | 把可读材料变成可执行约束 | 已运行 |
| 自主维护助手 | 处理“把质检报告改发另一个地址”类小请求 | 权限确认与下游影响判断 | 仍是目标 |
难点更实际：参与助手要处理实体混乱——会议笔记写 Sarah，邮件签名是全名，Slack 用昵称，负责人一个月后可能更换；工作流助手必须嵌入平台，才能检查设计是否漏掉例外、审批顺序是否颠倒；自主维护助手要判断请求是否来自有权修改的人、影响哪些下游节点，条件不满足时只生成变更建议。
底层是一张依赖图：节点有稳定含义，证据可追溯
支撑三个阶段的是一张依赖图：节点和边有稳定含义，能追溯到原始证据。审批有先后，同一人在邮件与 Slack 里可能有两个名字，流程可能包含回路；主干相当线性，复杂性来自分支、重试和循环。依赖图适合表达“哪些事实必须先成立”，也便于检查修改是否制造无法结束的环。技术选型是次要的：用图数据库或 PostgreSQL 表达皆可，重点是统一、可查询的公司表示——缺了这一层，“公司知识库”只是更多文档。
模型侧，Varick 在开源模型上做后训练，用强化学习教模型使用三类工具：实体消歧（两个拼写是否同一实体）、冗余循环检测（重复步骤）、DAG 违规检查（无环依赖中出现循环）。
Ramp 的请求 Agent：把一句“需要SAP集成”追问成规范
Ramp 的入口是“FDE requests” Slack 频道：客户成功、销售和客户经理在这里提交阻碍交易或采用的问题，有人只写一句“需要SAP集成”。内部请求 Agent 从追问缺失信息起步，多轮对话直到信息够写初步规范；工程总监 Leo Mehr 估算节省约 20% 的 scoping 时间——Ramp 演讲中的内部估算。第一版 Agent 只问几条缺失的问题，就把第一次响应从小时或天缩到秒，提交者在记忆新鲜时立即补充；它后来还配了企鹅形象——内部自动化同样有采用问题。
20% 只是第一阶段，更重要的是 scoping 变成可观察、可改进的问题序列：哪些字段最常缺失、哪些请求被否决，都能写回系统；Agent 只让信息更快齐全。上下文、范围、规范、实施四段的完整做法，见《AI项目范围界定（Scoping）怎么做》。
编码 Agent 进软件工厂：Factory 的四个关键词
Factory 把编码 Agent 放进端到端的“软件工厂”，CTO Eno Reyes 的出发点：模型本身不构成系统，相同模型放进不同 harness（Agent 运行框架），能做的工作完全不同。四个关键词：
- 模型无关 harness：模型可按任务路由和替换，上下文、权限、工具、验证与治理由企业掌握；
- trace 数据企业自有：执行轨迹是后续评测、改进和合规的基础，封在供应商系统里，企业难以演化自己的工厂；
- Missions 有界任务容器：长任务放进边界清晰的容器，人先说明“完成”由哪些检查证明，系统持续执行直到通过验证或触发升级；
- “潜艇里也能运行”：隔离能力——Agent 不能假设永远连着公共互联网；金融、医疗和政府环境里，代码、日志乃至提示上下文都是敏感数据。
自主程度有两类口径：完全自主完成的工作占比，Factory 在客户环境中观察到约 15% 到 20%；干预之间连续执行的占比，演讲中提到 80% 以上——少数任务端到端无人参与，但其中已能连续执行很长。两类数字均为 Factory 演讲中的项目经验与估计。
工具选型表：按 FDE 工作环节对号入座
按工作环节选工具，比按产品名选更稳：
| 环节 | 要解决的问题 | 工具形态 | 演讲中的代表 |
|---|---|---|---|
| 现场记录 | 把会议、邮件、消息变成可追溯上下文 | 参与助手/组织记忆 | Varick 参与助手 |
| 整理与依赖建模 | 把隐性流程变成统一可查询表示 | 依赖图、实体消歧、循环检测 | Varick 知识图 |
| 流程搭建 | 搭流程时补上遗漏的例外与依赖 | 嵌入平台的工作流助手 | Varick 工作流助手 |
| 需求收集与范围 | 把一句话请求追问成可判断的规范 | 请求型对话 Agent | Ramp 请求 Agent |
| 实现 | 依据明确规范完成中等规模功能 | 编码 Agent、有界任务容器 | Factory Droid 与 Missions |
| 评测 | 绑定交付结果、给失败建立形状 | 确定性验证循环、rubric | Factory Agent Readiness；指标见《企业AI项目怎么证明价值》 |
选型经验：上下文类工具先于实现类——Varick 先审计后实施，顺序颠倒只会给旧流程加一个聊天入口；评测没有现成产品，验证器要与客户共建。
Agent 先接管行政负担，判断仍然留给人
三家公司收敛到同一主张：Agent 先接管 FDE 的行政负担——资料整理、重复核查、信息追问、小型维护；最难的工作仍然留给人：让业务人员说出没写下来的例外，在风险、回报与接受度之间做设计。
Ramp 的说法是人变成评审者和编辑，集中使用“品味”；Factory 的说法是工程师转向设计“构建软件的系统”。Varick 创始人 Vasuman Moza 主张按整个部门思考回报：只自动化应付账款一小段，收益会被上下游等待抵消；他给出的 25%、50%、75% 回报属公司项目口径，取决于流程边界画在哪里。想补齐能力组合的人，转型路径见《怎么成为FDE》。
常见问题
FDE 需要哪些 AI 工具？
按工作环节配：现场记录用参与助手，流程整理用依赖图，搭建用工作流助手，实现用编码 Agent，评测用确定性验证循环。
代表案例来自三场演讲；选型先上下文类、后实现类。
AI Agent 能替代前向部署工程师吗？
2026 年的公开证据都指向“放大”：Agent 接管资料整理、重复核查和小型维护，人保留范围判断与客户责任。
Varick 的近期目标是扩张每名 FDE 能管理的上下文，Factory 观察到的完全自主程度约 15% 到 20%——理解成行政负担的接管者更接近现状。
企业怎么开始给 FDE 配 Agent？
从行政负担最重的一端起步：先做资料整理、需求追问这类低风险环节，Ramp 的第一版请求 Agent 就把响应缩到秒级。
起步前先定评测口径——解决率、转人工率加反指标，可参考选型表所附文章的结果合同示例；有了口径，节省才有可信的基线。