娜样学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应用人工智能工程和 FDEForward 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哪些操作能够自动执行哪些操作需要人工审批产品上线后怎样衡量效果两类工程师的侧重点可以总结为维度Agent SystemsApplied AI核心目标系统可靠性业务价值工作起点运行机制与技术问题用户需求与业务流程核心能力Runtime、Tools、State业务集成、产品交付交付物SDK、Harness、TracePRD、MVP、试点产品主要指标成功率、延迟、稳定性采用率、任务价值、ROI它们不是互斥的岗位。我更希望逐渐建立的是End-to-end AI Product Engineering端到端 AI 产品工程能力。也就是既知道怎样让 Agent 可靠执行任务也知道为什么值得开发这个 Agent。三、为什么 Agent 项目不应该从技术选型开始这是今天最重要的认知修正之一。我原来以为开发 Agent 项目应该先确定模型、框架、向量数据库和工具系统。实际上更合理的顺序应该是发现用户问题 ↓ 梳理业务流程 ↓ 确定产品目标 ↓ 明确 MVP 边界 ↓ 选择技术方案 ↓ 开发、验证与交付1. Jobs To Be Done用户真正需要完成什么任务Jobs To Be DoneJTBD可以理解为从用户需要完成的实际任务出发而不是从功能名称出发。例如企业客服的真实问题可能是客服人员需要频繁切换 CRM、订单系统和知识库希望减少重复查询提高客户请求处理效率。这比简单提出“开发一个客服 Agent”更有价值。因为我们已经知道了用户是谁企业客服人员。问题是什么跨系统查询耗时。希望改善什么减少重复操作。核心约束是什么不能增加错误操作。2. MVP不是功能越多越好MVPMinimum Viable Product最小可行产品的重点是用有限的功能验证核心价值假设。例如第一版企业客服 Agent 可以只做订单查询 企业知识库检索 客服回复草稿生成暂时不做自动退款、自动修改订单等高风险功能。为什么因为查询订单主要是读操作Read Operation而退款会改变真实业务状态属于写操作Write Operation风险完全不同。后者还需要额外考虑用户身份 ↓ 操作权限 ↓ 人工审批 ↓ 执行幂等性 ↓ 结果验证 ↓ 审计日志所以Agent 的自主程度应该与动作风险、验证能力和用户授权水平相匹配。这比盲目追求 Fully Autonomous Agent完全自主智能体更符合真实业务需求。四、从 PRD 到上线一个 Agent 项目怎样落地今天进一步理解了 PRDProduct Requirements Document产品需求文档的价值。以前容易认为 PRD 是产品经理负责的文档开发工程师只需要根据需求编写代码。但 Agent 开发涉及模型、工具、业务系统、权限和用户交互。如果没有明确需求技术方案很容易失控。1. PRD 不只是功能列表一份 Agent PRD 至少应该回答内容需要明确的问题用户与场景谁会使用为什么使用核心任务Agent 到底需要完成什么MVP 范围第一版做什么、不做什么数据来源从哪些系统获取可信数据工具权限允许读什么、写什么任务验收什么情况算真正完成异常处理失败、超时、权限不足怎么办上线指标成功率、成本、延迟要求是什么2. 将模糊需求转化为可验证条件例如需求Agent 能够查询订单。这个描述还不够清晰。可以使用 Given-When-Then 格式定义验收标准Given: 用户已经登录并拥有订单查询权限。 When: 用户询问某个订单的物流状态。 Then: Agent 调用正确的订单查询 API。 And: 返回信息与实际订单状态一致。 And: 权限不足时不披露敏感数据。 And: 完整执行过程可追踪、可审计。这样产品、后端、Agent 工程师和测试人员才能围绕相同的标准工作。3. 一个示例项目的交付阶段假设已有模型服务和必要的业务 API可以将项目规划成阶段示例周期主要产出需求探索第 12 周用户流程、PRD、MVP架构准备第 34 周接口、权限、技术设计开发集成第 58 周Agent Runtime、RAG、Tools评测试点第 911 周Eval Suite、试点报告灰度上线第 1214 周监控、回滚、运维交接这只是说明项目管理方法的示例周期不代表真实项目一定需要 14 周。而且评测应尽可能与开发并行不能等全部功能写完才开始验证。这里还涉及 Critical Path关键路径如果企业长期无法提供 API 权限其他功能开发得再快也可能无法按期交付。五、Agent Evaluation 为什么必须从模型指标走向业务指标上一篇重点学习了 Trajectory、Outcome Verifier 和 Task Success Rate。但今天意识到技术上的任务成功不一定等于产品上的成功。例如某个客服 Agent 的回答准确率很高但客服人员觉得操作复杂、响应速度慢最终仍然不愿意使用。这种情况下即使模型表现不错产品也未必成功。因此评测应该分成四层层次关注指标Model Quality回答准确性、格式合规Agent Quality工具选择、任务完成率、恢复能力User Experience耗时、满意度、纠正率Business Outcome实际采用率、成本变化、业务效率安全指标还需要独立设置硬约束不能通过较高的平均任务完成率来抵消严重越权或隐私泄漏。1. 用户对话次数多不代表产品价值高假设Agent A每天需要和用户对话 50 次。Agent B每天只需要对话 5 次就能完成同样的任务。不能仅凭对话次数判断哪个产品更成功。Google 的 HEART 用户体验评估框架提供了一个有价值的思路Happiness用户满意度。Engagement用户参与情况。Adoption新用户采用情况。Retention用户留存情况。Task Success任务成功情况。真正重要的是产品是否帮助用户以更低的成本、更少的操作完成任务。2. ROI 不能直接等于节省时间ROIReturn 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 系统可以先围绕 68 个业务工具完成以下目标实现一个具有明确读写权限的 Agent。构建离线任务评测集和 Outcome Verifier。编写一页 PRD明确目标用户与 MVP 范围。输出技术架构、风险清单和试点验收报告。这样一个项目虽然规模不大却能够完整回答为什么做怎么做怎样证明做成了这比单纯展示“我会调用 LangGraph API”更接近真实企业开发。八、今天最重要的三个认知修正认知一Agent 技术先进不代表产品有价值用户不会因为一个 Agent 使用了多个模型、复杂规划或多 Agent 架构就一定愿意使用它。技术方案应该服务于实际任务而不是成为产品开发的起点。认知二任务完成率高不代表商业上一定成功Agent Evaluation 需要覆盖模型质量、系统质量、用户体验和业务结果。真实价值必须通过使用情况、成本和效果进行验证。认知三FDE 不是简单的模型部署工程师FDE 的价值在于连接客户需求、AI 技术与生产系统并将成功实践沉淀为可复用能力。它要求工程师既能解决技术问题也能够理解业务约束和交付目标。九、今天留下的问题一个企业客服 Agent 的离线 Task Success Rate 已经达到较高水平但真实客服人员依然不愿意使用应该怎样区分产品设计问题和 Agent 能力问题同一套 Agent Harness 面向多个企业客户交付时哪些能力应该标准化哪些业务逻辑必须保留定制空间在企业 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 产品能力需要把技术、评测和业务交付连接起来。参考资料Cameron R. Wolfe — Agentic RL: Frameworks and Best PracticesAmazon AWS — Product Management at Amazon / Working BackwardsGoogle Research — Measuring the User Experience on a Large ScaleOpenAI — Forward Deployed Engineer注文中的 Agent 产品案例、项目周期及验收要求用于说明工程方法不代表已实施的真实项目或经过验证的实验数据。
娜样学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应用人工智能工程和 FDEForward 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哪些操作能够自动执行哪些操作需要人工审批产品上线后怎样衡量效果两类工程师的侧重点可以总结为维度Agent SystemsApplied AI核心目标系统可靠性业务价值工作起点运行机制与技术问题用户需求与业务流程核心能力Runtime、Tools、State业务集成、产品交付交付物SDK、Harness、TracePRD、MVP、试点产品主要指标成功率、延迟、稳定性采用率、任务价值、ROI它们不是互斥的岗位。我更希望逐渐建立的是End-to-end AI Product Engineering端到端 AI 产品工程能力。也就是既知道怎样让 Agent 可靠执行任务也知道为什么值得开发这个 Agent。三、为什么 Agent 项目不应该从技术选型开始这是今天最重要的认知修正之一。我原来以为开发 Agent 项目应该先确定模型、框架、向量数据库和工具系统。实际上更合理的顺序应该是发现用户问题 ↓ 梳理业务流程 ↓ 确定产品目标 ↓ 明确 MVP 边界 ↓ 选择技术方案 ↓ 开发、验证与交付1. Jobs To Be Done用户真正需要完成什么任务Jobs To Be DoneJTBD可以理解为从用户需要完成的实际任务出发而不是从功能名称出发。例如企业客服的真实问题可能是客服人员需要频繁切换 CRM、订单系统和知识库希望减少重复查询提高客户请求处理效率。这比简单提出“开发一个客服 Agent”更有价值。因为我们已经知道了用户是谁企业客服人员。问题是什么跨系统查询耗时。希望改善什么减少重复操作。核心约束是什么不能增加错误操作。2. MVP不是功能越多越好MVPMinimum Viable Product最小可行产品的重点是用有限的功能验证核心价值假设。例如第一版企业客服 Agent 可以只做订单查询 企业知识库检索 客服回复草稿生成暂时不做自动退款、自动修改订单等高风险功能。为什么因为查询订单主要是读操作Read Operation而退款会改变真实业务状态属于写操作Write Operation风险完全不同。后者还需要额外考虑用户身份 ↓ 操作权限 ↓ 人工审批 ↓ 执行幂等性 ↓ 结果验证 ↓ 审计日志所以Agent 的自主程度应该与动作风险、验证能力和用户授权水平相匹配。这比盲目追求 Fully Autonomous Agent完全自主智能体更符合真实业务需求。四、从 PRD 到上线一个 Agent 项目怎样落地今天进一步理解了 PRDProduct Requirements Document产品需求文档的价值。以前容易认为 PRD 是产品经理负责的文档开发工程师只需要根据需求编写代码。但 Agent 开发涉及模型、工具、业务系统、权限和用户交互。如果没有明确需求技术方案很容易失控。1. PRD 不只是功能列表一份 Agent PRD 至少应该回答内容需要明确的问题用户与场景谁会使用为什么使用核心任务Agent 到底需要完成什么MVP 范围第一版做什么、不做什么数据来源从哪些系统获取可信数据工具权限允许读什么、写什么任务验收什么情况算真正完成异常处理失败、超时、权限不足怎么办上线指标成功率、成本、延迟要求是什么2. 将模糊需求转化为可验证条件例如需求Agent 能够查询订单。这个描述还不够清晰。可以使用 Given-When-Then 格式定义验收标准Given: 用户已经登录并拥有订单查询权限。 When: 用户询问某个订单的物流状态。 Then: Agent 调用正确的订单查询 API。 And: 返回信息与实际订单状态一致。 And: 权限不足时不披露敏感数据。 And: 完整执行过程可追踪、可审计。这样产品、后端、Agent 工程师和测试人员才能围绕相同的标准工作。3. 一个示例项目的交付阶段假设已有模型服务和必要的业务 API可以将项目规划成阶段示例周期主要产出需求探索第 12 周用户流程、PRD、MVP架构准备第 34 周接口、权限、技术设计开发集成第 58 周Agent Runtime、RAG、Tools评测试点第 911 周Eval Suite、试点报告灰度上线第 1214 周监控、回滚、运维交接这只是说明项目管理方法的示例周期不代表真实项目一定需要 14 周。而且评测应尽可能与开发并行不能等全部功能写完才开始验证。这里还涉及 Critical Path关键路径如果企业长期无法提供 API 权限其他功能开发得再快也可能无法按期交付。五、Agent Evaluation 为什么必须从模型指标走向业务指标上一篇重点学习了 Trajectory、Outcome Verifier 和 Task Success Rate。但今天意识到技术上的任务成功不一定等于产品上的成功。例如某个客服 Agent 的回答准确率很高但客服人员觉得操作复杂、响应速度慢最终仍然不愿意使用。这种情况下即使模型表现不错产品也未必成功。因此评测应该分成四层层次关注指标Model Quality回答准确性、格式合规Agent Quality工具选择、任务完成率、恢复能力User Experience耗时、满意度、纠正率Business Outcome实际采用率、成本变化、业务效率安全指标还需要独立设置硬约束不能通过较高的平均任务完成率来抵消严重越权或隐私泄漏。1. 用户对话次数多不代表产品价值高假设Agent A每天需要和用户对话 50 次。Agent B每天只需要对话 5 次就能完成同样的任务。不能仅凭对话次数判断哪个产品更成功。Google 的 HEART 用户体验评估框架提供了一个有价值的思路Happiness用户满意度。Engagement用户参与情况。Adoption新用户采用情况。Retention用户留存情况。Task Success任务成功情况。真正重要的是产品是否帮助用户以更低的成本、更少的操作完成任务。2. ROI 不能直接等于节省时间ROIReturn 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 系统可以先围绕 68 个业务工具完成以下目标实现一个具有明确读写权限的 Agent。构建离线任务评测集和 Outcome Verifier。编写一页 PRD明确目标用户与 MVP 范围。输出技术架构、风险清单和试点验收报告。这样一个项目虽然规模不大却能够完整回答为什么做怎么做怎样证明做成了这比单纯展示“我会调用 LangGraph API”更接近真实企业开发。八、今天最重要的三个认知修正认知一Agent 技术先进不代表产品有价值用户不会因为一个 Agent 使用了多个模型、复杂规划或多 Agent 架构就一定愿意使用它。技术方案应该服务于实际任务而不是成为产品开发的起点。认知二任务完成率高不代表商业上一定成功Agent Evaluation 需要覆盖模型质量、系统质量、用户体验和业务结果。真实价值必须通过使用情况、成本和效果进行验证。认知三FDE 不是简单的模型部署工程师FDE 的价值在于连接客户需求、AI 技术与生产系统并将成功实践沉淀为可复用能力。它要求工程师既能解决技术问题也能够理解业务约束和交付目标。九、今天留下的问题一个企业客服 Agent 的离线 Task Success Rate 已经达到较高水平但真实客服人员依然不愿意使用应该怎样区分产品设计问题和 Agent 能力问题同一套 Agent Harness 面向多个企业客户交付时哪些能力应该标准化哪些业务逻辑必须保留定制空间在企业 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 产品能力需要把技术、评测和业务交付连接起来。参考资料Cameron R. Wolfe — Agentic RL: Frameworks and Best PracticesAmazon AWS — Product Management at Amazon / Working BackwardsGoogle Research — Measuring the User Experience on a Large ScaleOpenAI — Forward Deployed Engineer注文中的 Agent 产品案例、项目周期及验收要求用于说明工程方法不代表已实施的真实项目或经过验证的实验数据。
与快照完整实战)
