夜雨聆风编者按
这篇文章，是对我此前两篇文章——《揭秘SRPT：从零打造AI Agent的方法论》和《让AI Agent创造真实价值的KISS模型》——的一次重新梳理与升级。过去一段时间，我一边把“如何打造Agent”带进课堂，一边参与“估咕狮”等智能体的开发与迭代。授课迫使我把经验讲清楚，开发则不断用真实问题来检验这些方法。两者叠加，我越来越确定：原来的方向是对的，但框架还需要补上两块拼图。
第一块是Tools（工具）。原来的KISS模型把一部分工具能力放在Skills中讨论，在Agent主要“回答问题”的阶段，这样处理尚可使用；但当Agent开始搜索网页、读取数据库、操作软件、发送消息，甚至通过MCP连接更多外部系统时，“会怎么做”与“拿什么做”必须分开。因此，KISS需要升级为KISST。
第二块是经营。Agent的技术实现越来越方便，开发成本快速下降，但供给越多，用户的注意力并不会同步增加。能做出来，不等于有人用；有人用，不等于愿意付费；获得一次流量，也不等于能够持续经营。最近大热的FDE岗位，恰好为理解这两块拼图提供了一个很好的入口。
一、FDE为什么在今天火了
FDE，全称Forward Deployed Engineer，通常译作前线部署工程师。它并不是一个刚刚出现的岗位，但在生成式AI进入企业应用之后，突然变得格外引人关注。原因并不复杂：大模型能力越来越强，可真正把模型变成生产力，仍然需要有人走进客户现场，理解业务、拆解问题、搭建系统，并推动它真正被使用。
OpenAI对FDE的岗位描述很有代表性：FDE与客户并肩工作，把前沿模型转化为生产系统；从需求发现、技术范围界定、系统设计，到原型、上线与稳定运行，负责端到端交付；最终以生产采用、工作流影响和评估反馈来衡量成败。换句话说，FDE不是坐在后方等待需求文档的普通工程师，而是进入真实场景，在现实约束中把技术变成结果的人。
这恰恰解释了为什么AI时代需要FDE。模型是通用的，客户问题却是具体的；模型更新很快，企业流程、历史系统、权限边界和组织习惯却各不相同。两者之间存在一道巨大的“最后一公里”。FDE的价值，就是站在模型与业务的交界处，把模糊诉求翻译成可执行任务，再把技术能力组织成可使用、可评估、可维护的解决方案。
从这个角度看，FDE几乎天然需要学习SRPT+KISST（这个”T“不是打错了，是对KISS模型的一个升级，后面会说）：用SRPT看清场景、角色、问题与任务，用KISST补齐知识、数据、技能、流程与工具。但如果再向前追问一步，会发现FDE通常仍有一个相对有利的起点——客户已经出现，问题至少有了线索，合作范围和收费方式也往往经过了前期确认。FDE的核心挑战，是把已经承诺的价值交付出来。
那么，有没有一类人，比FDE更早进入现场？他们不仅解决现成问题，还主动发现尚未被定义的需求；不仅搭建Agent，还要寻找用户、获得流量、设计收费并承担失败风险。在我看来，这正是AI时代创业者的画像。我愿意借用同一个缩写，把他们称为另一种FDE：Forward Deployed Entrepreneur。
两种FDE，一条价值链｜Forward Deployed Engineer重在进入现场、交付价值；Forward Deployed Entrepreneur还要从无到有发现价值，并通过经营获取价值。
二、SRPT：先发现值得解决的问题
过去两年，Agent领域最常见的误区，是从技术名词出发：先选模型、框架、知识库，再四处寻找一个可以落地的场景。这本质上仍是“拿着锤子找钉子”。模型越强、工具越多，锤子看起来越漂亮；但如果没有真实问题，最后往往只是一个令人惊艳几分钟的Demo。
SRPT的作用，是把创造者从技术兴奋拉回现实。S是Scene（场景），R是Role（角色），P是Problem（问题），T是Task（任务）。它依次回答四个问题：事情发生在哪里？谁在其中行动？他真正遇到了什么阻碍？为了解决这个问题，需要完成哪些具体任务？
场景的尺度越大，角色越多，问题越复杂。对于资源有限的团队，与其一开始就做“万能助理”，不如从一个窄场景切入，服务一类清晰角色，解决一个高频或高价值问题。仍以股票估值为例，“帮助所有人做好投资”过于宏大；“帮助缺乏时间和专业能力的普通投资者，更快完成上市公司资料整理、关键假设分析与估值测算”，才是可拆解、可验证的起点。
角色也不是画像表格里的年龄、收入和职业标签，而是特定时空中的行动主体。同一个人在家庭、学校、公司和投资账户前，会切换成完全不同的角色。真正的产品需求，往往不是从“用户说自己想要什么”中直接得到，而是来自创造者对角色行为、限制与焦虑的长期观察。好产品常常始于一句很朴素的话：这件事为什么这么麻烦？能不能换一种做法？
问题明确之后，才进入Task。任务不是功能清单，而是为解决问题而设计的行动单元。一个复杂问题应被拆成“信息输入—处理分析—结果输出—反馈修正”的任务闭环，并逐一判断哪些由Agent完成，哪些用确定性程序或RPA完成，哪些必须保留给人。不是所有任务都需要Agent：规则稳定、容错度极低的环节，确定性系统往往更可靠；复杂且后果重大的环节，则应设置人工确认、权限边界与退出机制。
SRPT的核心提醒｜Agent只是解决问题的技术选项之一。先定义任务，再判断Agent是否合适；不要先决定使用Agent，再为它寻找任务。
三、从KISS到KISST：让Agent具备交付价值的能力
SRPT回答“打造什么”，KISST回答“凭什么做成”。KISST由Knowledge（知识）、Information & Data（资讯与数据）、Skills（技能）、SOP（标准流程）和Tools（工具）五个维度组成。五者不是简单相加，而更接近乘法关系：
Agent价值 = K × I × S × SOP × T
乘法意味着明显的短板效应：知识丰富却没有实时数据，判断可能过时；数据齐全却没有专业技能，只能堆砌材料；方法正确却没有工具，Agent只能给建议，不能完成行动；工具很多却没有流程和边界，则可能把错误执行得更快。
1. Knowledge：理解业务，知道什么是对的
Knowledge是Agent的领域知识与规则基础，决定它是否真正理解业务。投资分析Agent需要理解估值逻辑、会计口径和行业差异；课程助教Agent需要掌握教学目标、课程内容与评分原则；客户服务Agent则要理解产品政策、服务边界与异常处理规则。
知识建设不是把一堆PDF扔进知识库就结束了。它至少包括概念体系、业务规则、判断原则、反例与例外。高质量知识还需要结构化、版本化和可追溯：哪些内容长期有效，哪些会随政策与产品变化，哪些来源更具权威性，Agent应当能够区分。
2. Information & Data：掌握此刻正在发生什么
Knowledge偏向相对稳定的“常识与规则”，Information & Data则提供动态事实与任务上下文。股票价格、财务数据、项目进度、客户订单、日历安排、当前网页状态，都属于Agent完成当下任务所需的证据。
这一维度的关键不是“数据越多越好”，而是数据是否相关、及时、完整并有权限使用。Agent必须知道数据从哪里来、何时更新、发生冲突时信任谁，以及数据缺失时是停止、追问还是降级处理。没有数据治理，所谓“数据驱动”很容易变成“数据误导”。
3. Skills：掌握解决问题的方法
Skills指可复用的方法能力，而不是外部软件本身。例如：从长文中提取事实、用估值模型计算区间、比较多种方案、识别异常、生成图表、把复杂任务拆成子任务，以及检查初稿并持续改进。这些能力体现的是Agent“会不会做”。
吴恩达近年来反复强调的四类Agentic设计模式——反思、工具使用、规划与多Agent协作——也可以放进这一层理解。反思让Agent有机会检查并修正结果，规划帮助它拆解复杂任务，多Agent协作则像组织分工，让不同专长承担不同子任务。但复杂度不是目的。能用一个Agent和清晰流程解决，就不必为了“智能体军团”的形式感增加成本与失控风险。
4. SOP：把偶然成功变成稳定交付
SOP包含两层含义。第一层是Standard Operating Procedure，即先做什么、后做什么，何时分支、何时回退、何时交给人；第二层是Standard of Process，即每一步的输入标准、输出标准、质量门槛和决策规则。
OpenAI关于Agent搭建的实践指南也强调，应尽量把已有操作规程、支持脚本和政策文件转化为清晰指令，把密集流程拆成较小步骤，明确每一步对应的动作或输出，并覆盖常见边界情况。Anthropic则区分了工作流与更自主的Agent：任务清晰、可预测时，预先编排的工作流通常更稳定；只有当路径无法事先写死、需要模型根据环境动态决策时，才值得提高自主性。
因此，SOP不是为了束缚Agent，而是在确定性与灵活性之间划出边界：把确定的部分写清楚，把不确定的部分交给模型判断，再为高风险动作设置权限、验证和人工接管。
5. Tools：让智能真正连接现实世界
Tools是KISST新增的第五个维度。工具是Agent读取外部世界、执行动作和验证结果的接口，包括搜索引擎、数据库、计算器、代码执行环境、企业软件API、浏览器操作、邮件与日历，也包括通过MCP接入的各类服务。
OpenAI把“模型、工具、指令”视为Agent的基础组成，Anthropic也把检索、工具和记忆视为增强型大模型的核心扩展。两家的观点共同揭示了一件事：不能行动的Agent，很多时候只是一个更会说话的聊天机器人。
但工具并非越多越好。一个好工具应有清晰的名称、输入输出、权限范围、错误返回和使用说明；关键动作必须能够验证，不能把“Agent说已经发送”当作邮件真的发出，也不能把页面出现“成功”当作后台状态一定改变。工具数量过多还会增加选择错误，因此应从最小工具集开始，围绕任务逐步扩展。
Skills与Tools的区别｜Skills回答“会不会做”，Tools回答“能不能动手做”。会分析财报是Skill，调用金融数据库是Tool；会安排日程是Skill，写入日历并发出邀请是Tool。
四、真正的交付，不是能运行，而是可信赖
把KISST的五个维度准备齐，并不代表Agent已经完成。真正运行起来，它应形成一个循环：读取目标与上下文，依据知识和数据作出判断，运用技能形成计划，按照SOP选择工具执行，观察结果，再根据反馈修正，直到完成任务或触发人工接管。
这与Anthropic所描述的“计划—行动—观察—调整”循环一致，也与吴恩达强调的迭代式Agentic workflow相呼应。Agent的优势并不只是一次生成更长的答案，而是可以多轮工作：先做一部分，检查环境反馈，再决定下一步。
落地时，我建议坚持“最小可行Agent”。先选择SRPT中最重要、最可验证的一条任务链；为它提供最少但可靠的知识、数据与工具；把成功标准写成可以检查的结果；先用单Agent跑通，再判断是否需要并行、路由、评审Agent或多Agent协作。复杂架构应该来自真实瓶颈，而不是来自架构图的审美。
评估也必须从一开始进入系统。传统软件的同一输入通常得到同一输出，而Agent可能因为上下文、模型版本和工具状态不同产生差异。靠开发者偶尔试几次，很容易把“看起来不错”误判为“可以上线”。评估应从SRPT中的任务成功标准出发：任务是否完成，事实是否正确，步骤是否合规，工具动作是否真正生效，成本与时延是否可接受，何时需要人工介入。
对“估咕狮”而言，评估不能只看报告文字是否流畅，还应检查数据来源与日期、计算公式、关键假设、风险提示、引用可追溯性，以及Agent有没有越过“辅助判断”去替用户下结论。上线后的失败案例更要沉淀为回归测试，让每一次修复都能留下组织记忆。
五、FDE的下一步：从交付价值到创造一门生意
到这里，再回头看FDE，会发现它几乎完整覆盖了SRPT+KISST的能力要求。FDE进入一个具体场景，与客户中的不同角色协作，把模糊诉求还原为问题，再拆成可交付任务；随后补齐知识、数据、技能、流程和工具，把原型推入生产，并通过评估持续改进。优秀的FDE还会把一次性方案沉淀为工具、Playbook和可复用模块，让现场经验反向推动产品与模型进化。
但FDE的工作，通常从“客户已经在这里”等条件成立之后开始。客户为什么出现、这个问题是否足够普遍、产品如何被更多人发现、谁愿意为什么结果付费，这些更靠前也更商业的问题，往往由销售、产品或公司创始人承担。
Forward Deployed Entrepreneur则必须从更前面开始。他要走进那些连需求都没有被清楚表达的现场，从人们习以为常的麻烦、低效和妥协中，识别一个值得解决的问题；再把这个问题转化成Agent可以完成的任务，亲手做出第一版产品，找到第一批用户，并在真实使用中不断修正。
他还必须走得更远。Agent技术门槛正在下降，供给会越来越多，但人的时间、信任和注意力依然有限。因此，创业者不能只问“能不能做出来”，还要追问：用户为什么能发现我？为什么愿意持续使用？为什么愿意付费？每次交付的模型、工具、人工审核和获客成本，能否被收入覆盖？
这两类FDE并不是简单的高低之分，而是承担的风险不同。Forward Deployed Engineer主要承担交付风险：能否在复杂现场把承诺兑现。Forward Deployed Entrepreneur还要承担需求风险、产品风险和商业风险：问题是否真实，方案是否有人使用，商业模式能否成立。他必须同时具备三种能力——像产品创造者一样用SRPT发现价值，像FDE一样用KISST交付价值，再像企业经营者一样通过分发、留存、信任、收入与成本管理获取价值。
流量当然重要，但流量不是价值本身。它可以买来，注意力也可以短暂吸引，信任却只能靠连续交付建立。Agent一旦开始替用户行动，风险也随之上升：谁承担错误后果？谁可以撤销动作？数据如何保护？这些问题不只是安全问题，也是商业问题。缺乏信任的Agent，很难获得长期授权，更难进入高价值场景。
AI时代创业者的三种能力｜用SRPT发现价值，用KISST交付价值，再通过经营闭环获取价值。前两步让Agent有用，最后一步让Agent活下去。
六、SRPT+KISST+经营闭环：一张完整的落地清单
真正动手之前，可以依次回答下面这些问题。它们不是只检查KISST，而是从需求发现、能力搭建、可靠交付一直追问到持续经营。任何一个关键问题含糊，都可能在后续变成产品缺陷或商业风险。
第一组：用SRPT发现价值
Scene：事情具体发生在什么时间、空间与业务流程中？场景是否足够聚焦？
Role：谁是使用者，谁会受到影响，谁拥有决策权，谁承担结果？
Problem：用户现在如何解决？痛点有多频繁、多昂贵、多紧迫？
Task：完整任务链是什么？做到什么程度才算完成？哪些动作必须由人保留？
Fit：为什么要用Agent？确定性软件、RPA或人工服务是否反而更合适？
第二组：用KISST交付价值
Knowledge：需要哪些领域规则、判断原则、反例与例外？来源是否可信、可追溯？
Information & Data：需要哪些实时上下文？如何处理冲突、缺失、更新与权限？
Skills：Agent需要哪些分析、规划、反思、协作与表达能力？
SOP：步骤、分支、质量门槛、失败回退和人工接管如何定义？
Tools：最小工具集是什么？每个工具的权限、错误返回与验证机制是什么？
Evals：用哪些测试证明任务真的完成，而不是“看起来完成”？
Guardrails：哪些动作禁止自动执行？哪些必须二次确认？发生意外如何停止和撤销？
第三组：用经营闭环获取价值
Distribution：第一批用户在哪里？产品如何进入他们原有的工作流、平台或社群？
Activation：用户第一次使用时，多久能够感受到一个清晰、可衡量的结果？
Retention：什么理由让用户下周、下月仍然回来？产品是否会越用越贴合？
Trust：如何通过透明、可控和稳定交付积累授权，而不只是吸引一次注意？
Revenue：谁愿意为哪个结果付费？按次、订阅、项目制还是效果分成更合理？
Economics：收费能否覆盖模型、工具、人工服务、运维与获客成本？
Evolution：由谁持续维护知识、数据、工具、评估和业务规则？何时升级、收缩或退出？
结语：未来真正稀缺的，不只是会搭Agent的人
回头看，SRPT、KISST与经营闭环其实延续着同一条朴素逻辑：技术最终要回到人，能力最终要落到事，产品最终要经得起市场检验。SRPT帮助我们看见场景中的角色与问题，KISST帮助Agent获得完成任务所需的知识、数据、技能、流程与工具，经营闭环则让价值能够被发现、被信任、被持续使用并转化为收入。
未来，Agent技术还会继续变简单。也许很快，“会不会搭Agent”就像今天“会不会做网页”一样，不再构成长期壁垒。FDE仍然会是非常重要的岗位，因为大量企业需要有人深入现场，把通用模型转化为具体生产力。但更稀缺的，可能是那些能够主动定义场景、创造需求，并把Agent经营成一门可持续生意的人。
这就是我所理解的Forward Deployed Entrepreneur：他不是坐在办公室里凭空想象需求，也不是拿着现成方案四处推销，而是长期站在真实世界的一线，在具体的人、具体的问题和具体的约束中发现机会，再用技术、产品与经营把机会变成价值。
简单即强大。但真正的简单，从来不是少做一层思考，而是把复杂问题的关键结构看清楚。
参考资料
OpenAI：《A practical guide to building agents》，https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/
OpenAI：《Forward Deployed Engineer (FDE) - Seattle》岗位说明，https://openai.com/careers/forward-deployed-engineer-%28fde%29-seattle-seattle/
Anthropic：《Building effective agents》，2024-12-19，https://www.anthropic.com/engineering/building-effective-agents
Anthropic：《Demystifying evals for AI agents》，2026-01-09，https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
DeepLearning.AI / Andrew Ng：《Agentic AI》课程及Agentic Design Patterns系列，https://www.deeplearning.ai/courses/agentic-ai
