企业官网建设流程全解析

娜样学AI（二十二｜22）：从 LLM 到 Agent（下）——从工程实现到产品交付，FDE 为什么值得关注？

2026年10月10日

关键词：Agent Systems、Applied AI、PRD、MVP、Agent Evaluation、Product Engineering、FDE

一、今天学了什么

前两篇分别学习了 Agent Harness、Tool Calling、Trajectory、Evaluation 和 SFT 数据闭环。

今天开始思考一个更贴近实际工作的问题：

一个 Agent 技术上能够运行，是否就意味着它值得被开发成产品？

假设我们掌握了 LLM、RAG、LangGraph、MCP 和工具调用，就一定能开发出有价值的 AI 产品吗？

答案显然不是。

同样一套技术，可以用于企业客服、个人助理、科研助手或者企业工作流，但不同场景的需求、权限、风险和交付标准完全不同。

今天真正建立的理解是：

Agent 工程不仅要解决“系统怎样可靠地执行任务”，还需要回答“为什么要执行这些任务，以及怎样证明它为用户创造了价值”。

这也是我开始关注 Applied AI（应用人工智能工程）和 FDE（Forward Deployed Engineer，前沿部署工程师）的原因。

二、Agent Systems Engineer 和 Applied AI Engineer 有什么区别？

以前理解 Agent 开发岗位时，我主要关注技术能力：

LLM ↓ RAG ↓ Agent Framework ↓ Tool Calling ↓ Deployment

但实际上，企业真正需要的不只是会使用这些技术的人。

1. Agent Systems Engineer：关注系统能不能可靠运行

这类工程师主要负责 Agent 的底层能力和运行可靠性。

例如：

• Runtime：管理执行生命周期。
• Context Builder：构建模型上下文。
• Tool Registry：管理工具定义。
• State / Memory：维护任务状态与记忆。
• Tracing：记录执行轨迹。
• Permission：控制工具执行权限。
• Reliability：处理超时、失败恢复和并发。

假设 Agent 一直重复调用同一个工具，却没有完成任务。

Agent Systems Engineer 需要排查：

模型是否重复生成相同动作？ ↓ Observation 是否正确回传？ ↓ State 是否及时更新？ ↓ 终止条件是否合理？ ↓ Harness 是否正确控制执行？

它的关注重点是：如何让 Agent 在复杂环境中稳定、可靠地执行任务。

2. Applied AI Engineer：关注产品能不能解决真实问题

Applied AI Engineer 不仅需要理解模型和系统，还需要把技术能力映射到业务场景。

例如企业提出：

我们想开发一个智能客服 Agent。

Applied AI Engineer 不能马上回答：

使用 Qwen + LangGraph + RAG + MCP。

因为这只是技术栈，并没有解释为什么需要这些技术。

更应该先调查：

• 客服每天最耗时的操作是什么？
• 是查订单、查政策，还是处理退款？
• 现有系统有哪些 API？
• 哪些操作能够自动执行？
• 哪些操作需要人工审批？
• 产品上线后怎样衡量效果？

两类工程师的侧重点可以总结为：

它们不是互斥的岗位。

我更希望逐渐建立的是End-to-end AI Product Engineering（端到端 AI 产品工程）能力。

也就是既知道怎样让 Agent 可靠执行任务，也知道为什么值得开发这个 Agent。

三、为什么 Agent 项目不应该从技术选型开始？

这是今天最重要的认知修正之一。

我原来以为：

开发 Agent 项目，应该先确定模型、框架、向量数据库和工具系统。

实际上：

更合理的顺序应该是：

发现用户问题 ↓ 梳理业务流程 ↓ 确定产品目标 ↓ 明确 MVP 边界 ↓ 选择技术方案 ↓ 开发、验证与交付

1. Jobs To Be Done：用户真正需要完成什么任务？

Jobs To Be Done（JTBD）可以理解为：从用户需要完成的实际任务出发，而不是从功能名称出发。

例如企业客服的真实问题可能是：

客服人员需要频繁切换 CRM、订单系统和知识库，希望减少重复查询，提高客户请求处理效率。

这比简单提出“开发一个客服 Agent”更有价值。

因为我们已经知道了：

• 用户是谁：企业客服人员。
• 问题是什么：跨系统查询耗时。
• 希望改善什么：减少重复操作。
• 核心约束是什么：不能增加错误操作。

2. MVP：不是功能越多越好

MVP（Minimum Viable Product，最小可行产品）的重点，是用有限的功能验证核心价值假设。

例如第一版企业客服 Agent 可以只做：

订单查询 + 企业知识库检索 + 客服回复草稿生成

暂时不做自动退款、自动修改订单等高风险功能。

为什么？

因为查询订单主要是读操作（Read Operation），而退款会改变真实业务状态，属于写操作（Write Operation），风险完全不同。

后者还需要额外考虑：

用户身份 ↓ 操作权限 ↓ 人工审批 ↓ 执行幂等性 ↓ 结果验证 ↓ 审计日志

所以：Agent 的自主程度应该与动作风险、验证能力和用户授权水平相匹配。

这比盲目追求 Fully Autonomous Agent（完全自主智能体）更符合真实业务需求。

四、从 PRD 到上线：一个 Agent 项目怎样落地？

今天进一步理解了 PRD（Product Requirements Document，产品需求文档）的价值。

以前容易认为 PRD 是产品经理负责的文档，开发工程师只需要根据需求编写代码。

但 Agent 开发涉及模型、工具、业务系统、权限和用户交互。如果没有明确需求，技术方案很容易失控。

1. PRD 不只是功能列表

一份 Agent PRD 至少应该回答：

2. 将模糊需求转化为可验证条件

例如需求：

Agent 能够查询订单。

这个描述还不够清晰。可以使用 Given-When-Then 格式定义验收标准：

Given: 用户已经登录，并拥有订单查询权限。 When: 用户询问某个订单的物流状态。 Then: Agent 调用正确的订单查询 API。 And: 返回信息与实际订单状态一致。 And: 权限不足时不披露敏感数据。 And: 完整执行过程可追踪、可审计。

这样产品、后端、Agent 工程师和测试人员才能围绕相同的标准工作。

3. 一个示例项目的交付阶段

假设已有模型服务和必要的业务 API，可以将项目规划成：

这只是说明项目管理方法的示例周期，不代表真实项目一定需要 14 周。

而且评测应尽可能与开发并行，不能等全部功能写完才开始验证。

这里还涉及 Critical Path（关键路径）：如果企业长期无法提供 API 权限，其他功能开发得再快，也可能无法按期交付。

五、Agent Evaluation 为什么必须从模型指标走向业务指标？

上一篇重点学习了 Trajectory、Outcome Verifier 和 Task Success Rate。

但今天意识到：技术上的任务成功，不一定等于产品上的成功。

例如某个客服 Agent 的回答准确率很高，但客服人员觉得操作复杂、响应速度慢，最终仍然不愿意使用。

这种情况下，即使模型表现不错，产品也未必成功。

因此评测应该分成四层：

安全指标还需要独立设置硬约束，不能通过较高的平均任务完成率来抵消严重越权或隐私泄漏。

1. 用户对话次数多，不代表产品价值高

假设：

• Agent A：每天需要和用户对话 50 次。
• Agent B：每天只需要对话 5 次，就能完成同样的任务。

不能仅凭对话次数判断哪个产品更成功。

Google 的 HEART 用户体验评估框架提供了一个有价值的思路：

• Happiness：用户满意度。
• Engagement：用户参与情况。
• Adoption：新用户采用情况。
• Retention：用户留存情况。
• Task Success：任务成功情况。

真正重要的是：产品是否帮助用户以更低的成本、更少的操作完成任务。

2. ROI 不能直接等于节省时间

ROI（Return on Investment，投资回报率）也是需要谨慎理解的指标。

例如 Agent 每天替员工节省 30 分钟，不代表企业一定能够直接获得对应的人力成本收益。还需要考虑：

模型 API 成本 + 系统集成成本 + 人工复核成本 + 错误处理成本 + 长期维护成本

而且节省的时间是否真正转化为产能提升或费用下降，也需要实际验证。

这就是为什么业务结果需要单独评估，不能直接由技术指标推导。

六、FDE 为什么值得 AI Agent 工程师关注？

FDE 的完整名称是：Forward Deployed Engineer（前沿部署工程师）。

以前我容易将它理解成：

去客户现场部署模型和软件的工程师。

但这个理解明显太窄。

根据 OpenAI 的 FDE 岗位描述，其职责可能贯穿需求发现、技术方案设计、开发、生产上线、客户采用和效果反馈。

它更强调：工程师直接面对真实业务问题，并对技术方案能否交付和产生价值承担责任。

典型工作链路可以理解为：

客户业务问题 ↓ Product Discovery ↓ 技术可行性分析 ↓ 设计 AI 解决方案 ↓ 开发和系统集成 ↓ 生产部署与评测 ↓ 客户使用和反馈 ↓ 沉淀可复用能力

FDE 和普通 Agent 开发最大的区别是什么？

我认为不是谁的技术水平更高，而是职责覆盖范围不同。普通 Agent 开发岗位可能主要负责一个已经定义清楚的技术模块。FDE 则通常需要进一步参与：

• 业务需求判断。
• 与客户和其他团队沟通。
• 技术方案取舍。
• 系统集成与上线。
• 衡量真实业务效果。
• 沉淀可复用的工程方案。

例如一个企业已经完成客服 Agent 试点。

如果每增加一个客户，都要重新编写全部工具和运行逻辑，那么交付成本可能很高。

更合理的方式是把通用部分沉淀下来：

Tool Adapter + Permission Control + Agent Runtime + Evaluation Harness + Trace / Monitoring + Deployment Playbook

然后根据不同客户的业务特点调整配置和集成逻辑。这也是 FDE 与产品工程能力之间的重要联系。

不过 FDE 并不适合所有工程师。它通常要求更强的沟通、客户协作和交付能力，具体岗位也可能涉及较多出差或定制开发，需要区分产品化工程与重复性项目实施。

七、我应该怎样培养端到端 Agent 产品工程能力？

今天最后形成的一个理解是：只会模型算法不够，只会拼 Agent Demo 也不够。

我更认可 T 型能力结构。纵向需要具备足够深入的技术能力：

Agent Runtime RAG Tool Calling State / Memory Evaluation SFT 数据 Deployment Reliability

横向则需要理解：

Product Discovery PRD MVP 用户体验 项目管理 成本与 ROI 产品交付

一个适合练习的项目是企业项目管理 Agent。

不必一开始就开发复杂的多 Agent 系统，可以先围绕 6～8 个业务工具完成以下目标：

1. 实现一个具有明确读写权限的 Agent。
2. 构建离线任务评测集和 Outcome Verifier。
3. 编写一页 PRD，明确目标用户与 MVP 范围。
4. 输出技术架构、风险清单和试点验收报告。

这样一个项目虽然规模不大，却能够完整回答：为什么做？怎么做？怎样证明做成了？

这比单纯展示“我会调用 LangGraph API”更接近真实企业开发。

八、今天最重要的三个认知修正

认知一：Agent 技术先进，不代表产品有价值

用户不会因为一个 Agent 使用了多个模型、复杂规划或多 Agent 架构，就一定愿意使用它。

技术方案应该服务于实际任务，而不是成为产品开发的起点。

认知二：任务完成率高，不代表商业上一定成功

Agent Evaluation 需要覆盖模型质量、系统质量、用户体验和业务结果。

真实价值必须通过使用情况、成本和效果进行验证。

认知三：FDE 不是简单的模型部署工程师

FDE 的价值在于连接客户需求、AI 技术与生产系统，并将成功实践沉淀为可复用能力。

它要求工程师既能解决技术问题，也能够理解业务约束和交付目标。

九、今天留下的问题

1. 一个企业客服 Agent 的离线 Task Success Rate 已经达到较高水平，但真实客服人员依然不愿意使用，应该怎样区分产品设计问题和 Agent 能力问题？

2. 同一套 Agent Harness 面向多个企业客户交付时，哪些能力应该标准化，哪些业务逻辑必须保留定制空间？

3. 在企业 Agent 项目中，Agent Engineer、Applied AI Engineer 和 FDE 应该怎样划分职责，才能避免需求、开发和上线验收之间出现断层？

十、总结

写完《从 LLM 到 Agent》上、中、下三篇，我逐渐建立了一条完整的理解链路。

上篇：Agent 为什么需要 Harness？

理解模型生成、工具执行、状态管理和 Agent Loop，让模型的决策真正进入外部环境。

中篇：Agent 怎样证明自己完成了任务？

通过 Trajectory、Outcome Verifier、Evaluation 和数据闭环，让 Agent 的执行过程可以追踪、失败可以定位，模型能力可以持续改进。

下篇：Agent 怎样真正成为有价值的产品？

从用户需求和 MVP 出发，通过 PRD、工程交付、产品评估和实际业务指标，判断 Agent 是否值得开发、是否真正创造价值。

我今天最大的收获是：

Agent Systems Engineering 决定系统能否可靠行动，Applied AI Engineering 决定这些行动是否解决真实问题。真正的端到端 AI 产品能力，需要把技术、评测和业务交付连接起来。

参考资料

1. Cameron R. Wolfe — Agentic RL: Frameworks and Best Practices
2. Amazon AWS — Product Management at Amazon / Working Backwards
3. Google Research — Measuring the User Experience on a Large Scale
4. OpenAI — Forward Deployed Engineer

注：文中的 Agent 产品案例、项目周期及验收要求用于说明工程方法，不代表已实施的真实项目或经过验证的实验数据。