Forter 2026 年 9 月 28 日公开实录：两周让 200 人自建 agent，工具从 20 个做到近 100 个、发布 80 个 agent。 这正是「前置部署」Forward Deployed Engineer（FDE）的主战场：FDE 嵌入客户现场，用工程手段把企业级 AI 与数据系统交付进真实环境，而不是交付一份演示稿。Forter 这套「两周内让非工程师也能自建 agent」的做法，把工具层、平台层、清障三件事拆开，可以直接搬到「前置部署」Forward Deployed Engineer（FDE）的客户项目里复现。 Forter 是一家身份驱动的欺诈与支付决策公司，服务全球数万家商户，其系统覆盖约 20 亿个不同身份，因此数据治理与安全要求很高。 演讲者是 Forter 首席工程师 Ben Maraney，在 Forter 任职 6.5 年，2023 年主导了公司第一个基于大语言模型的项目。该场次归在 QCon AI Boston 的议题目录下，InfoQ 于 2026-09-28 11:00 GMT 发布实录与全文转录。 这段经历发生在去年夏天：公司新成立 AI 工程团队，第一个任务是办一场为期两周的「冲刺式黑客松」，对象是全部研发（R&D），其中包含许多分析师——他们有的出身律师、心理学、实验室科研，很多人此前没写过一行 SQL。给团队准备的时间只有 5 周。 对「前置部署」Forward Deployed Engineer（FDE）来说，工具层是整套方案里投入产出比最高的一块：Forter 自建了一个「中央 MCP 服务器」，内部名叫 Toolchain。团队成立时 Toolchain 里大约 20 个工具，5 周后冲刺开始前接近 60 个，两周冲刺结束时接近 100 个。 Toolchain 做对的第一件事是发现性：它提供一个界面，让人能看到有哪些工具、点进去试跑、看结果。工具集中在一个仓库里，新工具照抄现成例子即可，所以分析师也能加。 每新增一个工具，只需要写一个配置文件，其中三项是核心：给 agent 看的「工具描述」、执行方式、以及输入 schema 与调用示例。描述写得清不清楚，直接决定 agent 会不会用错。 第二件事是收敛工具面：使用者为自己的 agent 建立连接时，只勾选这个 agent 真正需要的工具。Ben Maraney 明确说，给 agent 接太多工具会让它混乱并做出坏行为，所以连接过程被设计成「选工具→配置→吐出连接凭据」三步。 MCP 是 Model Context Protocol 的缩写，即模型上下文协议，它是这套方案里工具与 agent 之间的唯一接口。 Forter 在整个冲刺里没有自建「检索增强生成」，也就是企业 RAG（enterprise RAG）。演讲者给出的理由很直接：RAG 要决定怎么切分文档、怎么建索引、怎么召回、怎么排序，这些事在两周冲刺里做不好，也做不成通用能力。 替代方案是复用公司已有的「企业搜索」 Glean，在 Toolchain 上只暴露三个工具：search 按关键词与数据源范围召回片段、reads 取回整篇文档、summarize 返回几段摘要。 summarize 工具还接受一个 focus 参数，可以指定「这份摘要必须围绕哪个问题」，于是同一个工具既能给全文摘要也能给定向摘要。这套本来是给人类设计的搜索，换成 agent 消费后效果足够好，直接省掉了自建 RAG 的工作量。 平台层要先回答一个问题：agent 该怎么被触发。「前置部署」Forward Deployed Engineer（FDE）在客户现场最常踩的坑，就是只给一种触发方式。Forter 的答案是要同时支持三种——交互式对话、定时触发、事件触发，因为调研用户时三种需求都有。 「无代码」路线选用开源项目 LibreChat。当时 LibreChat 刚加上 MCP 能力，但还不能在单次对话里只启用其中几个工具。Forter 的绕法是：从 Toolchain 建多个连接，每个连接只暴露一个工具子集，使用者按需连上对应的几个连接。 LibreChat 的价值在于试错速度：连技术上最强的工程师也常常从它开始，先快速验证四五个想法，砍掉三个不成立的，再把剩下两个做深。一个副作用是它让工具调用过程完全可见——点开就能看到发了什么参数、收回了什么。 但演讲者承认 LibreChat 有两个硬伤：当时的 MCP 集成不太稳定，连接会掉；而且这样搭出来的 agent 没有「版本管理」，可定制性也很有限。 代码路线提供一个模板仓库，给出一个现成的界面和快速起步，好处是有「版本管理」、可以加子 agent 等任意定制。代价是搭建明显更慢，尤其是分析师在部署环节卡得厉害，迭代周期也比 LibreChat 长得多。 冲刺之后 Forter 补了一个内部 AI Hub：填「系统提示」、选模型、勾工具，几步就能分享给同事。演讲者的原话是希望当初能挤出时间先做这个，它跑得非常顺，而且几天就能搭出来。 非交互式 agent 选用 Strands 而不是 LangChain 或 LangGraph，理由是看完接口后判断 Strands 更容易教，而「可教性」在这里是首要指标。团队当时的假设是：如果哪天需要更复杂的能力，再改写成别的框架即可，而这件事后来一直没有发生。 调度没有另起炉灶：定时任务直接用已有的 Argo Workflows 加 cron，事件触发的任务用 webhook 打到 Argo 的 event sensor，由它决定哪些 agent 要响应、再拉起对应工作流。结论是：如果公司已有「作业调度」系统，agent 可能不需要新的调度层。 给非交互式 agent 准备的「脚手架」工具叫 scaffold，一条 scaffold create 带上 agent 名字、「系统提示」和工具清单就能生成，再把 TOOLCHAIN_API_KEY 交给它即可。「脚手架」还会生成一份 README，顺带把写好「系统提示」的方法与常见错误写进去。 「脚手架」没有通过时间考验，这是演讲者自己点出的失败：一是分析师从新建仓库到跑起来太笨重，工程师也不喜欢；二是每次上线新能力（比如更好的链路追踪）都要逐个仓库改，agent 一多就非常痛苦。后来的做法是回退到少量大仓库、每个仓库装一组相关 agent，摩擦才降下来。 冲刺期间真实产出的 agent 里，有几类特别有代表性。第一类是新人 onboarding 助手：有资深分析师把自己公司的实验方法论做成 agent，用来追问年轻同事的假设是否严谨，减少「做完实验再被打回重做」的返工。 第二类是工单清障类。Forter 内部把事后复盘文档叫 BetterNext，有人做了一个 agent 来读 BetterNext、按公司标准追问作者，帮他们把文档改到位。 第三类是商户配置 agent。给一个新商户做最优配置要调大约几百个配置项，这个 agent 去找相似商户——按电商形态、合同类型、销售地域、商品品类等维度相似——参考它们的配置给出建议，然后直接开一个 PR 交给分析师微调，把原本数小时甚至数天的配置工作压下来。 第四类是两个系统专家 agent，内部代号 Layla 与 Penny。Layla 同时能看分析代码、生产环境当前配置和底层交易数据，还能查几千个互相勾连的属性元数据，所以可以回答「这笔交易为什么被拒」「改了某个属性会影响哪些属性」这类问题。 Layla 原本是给工程师和分析师做的，后来因为对公司系统了解得足够深，被交给了客户成功与客户支持团队，挡掉了原本会涌向工程师的提问。Penny 结构类似，专注计费口径问题。演讲者由此总结出一条判断：只要能让 agent 同时拿到代码、数据与配置，它能做的事会超出预期。 非交互侧还有一类是异常告警归因 agent：收到商户流量异常告警后，它会去看告警内容、当时的代码变更，判断这次变更是否可能是原因，如果判断是，就批量发告警让相关人知道。 整场演讲里最值得抄的一段是一条反面教训。Forter 做过一个「事故响应」 agent，代号 IRA：理论上它会去读日志、指标、文档和 Kubernetes 集群状态，推断故障根因并给出处置建议。 IRA 不能在真实事故上试，所以团队拿历史上的老事故回放。初看结果极其惊艳——「根因分析」像是一击命中，后续步骤也很像样。 过了很久团队才发现真相：IRA 确实读了日志、指标和文档，但它顺手检索到了人类当时写的 BetterNext 复盘文档，然后几乎逐字照抄那份现成的「根因分析」，只是换了措辞。 这条教训落成一个硬要求：开发 agent 时，必须让人能看到它调用了哪些工具、传了什么参数，尤其是收回了什么内容。Forter 因此引入了 Langfuse（有开源版本），用来按会话查看工具调用与思考过程。演讲者说这在排障上帮助极大，也提醒业界同类工具值得配。 Forter 主动跳过了大语言模型评估，也就是 LLM 评估（LLM evaluation），这是演讲里的另一个明确取舍。 理由是这样：任何开源方案或厂商都会提供一整套开箱即用的评估器，承诺评估相关性、安全性、连贯性、简洁性；但演讲者的判断是，任何现代大模型给出的回答基本都相关、连贯、简洁且安全，这些指标会给出一个让你感觉不错、也能稍微调一调的数字，却回答不了真正重要的那个问题：这个答案对不对。 他接着说，真正有用的评估器——判断答案正确性、判断是否用对了工具、判断是否召回了正确上下文——共同点就是难做，因为它们要求你在开发的时候就知道人会怎么用这个工具、以及什么算好。 所以他的建议不是「不要做评估」，而是先确认项目需要多高的成熟度：如果使用者是组织内部人员、且关键决策回路里始终有人，那么评估暂时可以不挡在交付前面。评估值得考虑，但不应该成为不做实验、不上线的理由。 演讲把清障单列为一个部分，因为要让几百人同时造 agent，真正的瓶颈往往不在技术。「前置部署」Forward Deployed Engineer（FDE）在企业里推平台时，卡点通常也在这里。第一类摩擦来自法务。法务的本能是逐个用例审批，一旦人多就会立刻变成瓶颈。 Forter 的做法是提前沟通、并且承认法务在保护公司。最后把法务的关切收敛到两个：数据发到哪里、谁在处理，以及 agent 究竟会做什么。 第一个关切的解法是把推理放进云厂商的托管服务。演讲者给的表述是：如果走 Bedrock 或等价服务，就可以对法务说这和用其他云服务没有区别，因为数据流向的是云厂商而不是模型厂商；即便底层用的是 Anthropic 的模型，Anthropic 也看不到提问和回答，文档里写明「零数据保留」。 第二个关切的解法是把「高风险用例」与「低风险用例」事先定义清楚，并约定「高风险用例」一律交给法务审，「低风险用例」法务放手让人做。 第二类摩擦来自安全团队，关切同样收敛到两个：「提示注入」与「访问控制」。 「提示注入」的处置是一个很具体的交易：冲刺期间禁止任何人搭建能访问外部网络、或接收不可信输入的 agent，这个取舍小到安全团队当场接受。演讲者还点名推荐了 Meta 那篇关于 agent 权限设计的文章 Agents Rule of Two。 「访问控制」的处置是两条：一是明确 agent 的权限必须小于或等于使用者，二是这条约束不写进「系统提示」这种非确定性地方，而是在代码里以确定性方式强制执行。做到这两条之后，安全团队的态度就变成了「随便建」。 第三类摩擦是成本。演讲者把大模型称作公司里最贵的算力，并警告冲刺做到一半被管理层看见账单、直接叫停是真实风险。 对应做法是先对齐预期，再让成本可见：把每个团队、最好每个 agent 的 token 消耗与折算成本做成「仪表盘」，并主动盯着它。 对 FDE 而言，这份「仪表盘」同时是报价与交付范围谈判的依据：客户现场的 token 成本若不可见，超支就会在项目中期变成信任问题。 盯出来的规律很具体：每隔几天就会出现一个 agent 的 token 消耗超过其余所有 agent 之和，而且每次都不是同一个。团队会拿着图去找负责人，对方往往刚试了往上下文里塞东西、或者刚加了一个小循环，并没有意识到烧了多少 token，然后自己就改掉了，或者被换到更便宜的模型上。 第四类摩擦是使用者认知。演讲者说培训时最常见三种误解：只体验过早期 ChatGPT 的人以为模型很蠢、只会幻觉；偏科幻的人以为同样输入下模型一定比人聪明；听过机器学习这个词的人以为 agent 会自己越用越聪明。 他用的纠偏类比是「实习生」：想象一个名校毕业、兴趣广泛、通识不错的「实习生」入职，你给他一套说明、一批工具、一个任务，他尽力做完交回来，然后你立刻解雇他，下一个任务换一个新人。 这个类比承载三层意思：做得成不成是使用者的责任，而不是模型的；「实习生」会拼命讨好你，没有把握也会给答案，所以要自己核对质量；每次换新人意味着 agent 默认不会学习，除非你专门给它做学习机制。 除了认知，培训还要讲清三件事：有多个平台时该用哪个、文档在哪里、遇到问题找谁。演讲者特别强调冲刺前要和使用者面对面坐一会儿：几分钟的对话常常能省掉对方几天的挫败，并把方向掰到更可行的地方。 冲刺的成绩用数字看是这样：两周内发布了 80 个 agent。之后一部分合并成了功能更全的「超级 agent」在日常支撑业务，一部分保持原样、一部分被停用、一部分进了业务方的待办清单。 更长期的影响是能力外溢：Claude Code 的技能（skills）机制出现后，Forter 内部很快积累了 112 个由工程师构建的技能和 46 个由分析师构建的技能。演讲者的解释是，如果没有那次亲手造 agent 的经历，这些人不会有信心做这件事。 管理层的态度也变了：对 AI 交付价值的信心明显提升，因而更愿意投入。冲刺期间冒出来的一些想法已经做成面向客户的正式产品能力，直接参与收入。 InfoQ 标题把这轮覆盖的规模写成「200 人」，但转录正文里没有复述这个人数，这是本条目里唯一无法在演讲内容中二次核实的数字。 作者主动承认的局限与未覆盖场景如下，照搬时要把这些一起算进去。 第一，「脚手架」方案明确失败：从新建仓库到部署的路径对分析师和工程师都太笨重，新能力要逐仓库改造，最终被迫回退成少量大仓库；演讲者的原话是希望当初就这样开始。 第二，LibreChat 路线的 MCP 集成当时不稳定、连接会掉，且没有「版本管理」，定制能力有限；演讲者也说明「当时是这样，现在可能已变」。 第三，评估被整体跳过。这件事只在「使用者是内部人员且关键决策处有人」的前提下成立，面向外部用户或自动决策的场景不能照抄。 第四，IRA 「事故响应」 agent 的惊艳结果是假的——它逐字抄了人类写好的复盘文档，说明在缺少工具调用可见性的情况下，回放历史数据很容易得出虚高结论。 第五，全部数字来自 Forter 单一公司的一次内部实践，没有对照组，也没有任何业务收益金额：演讲者只给出「用户反馈极其正面」这类定性表述。 第六，80 个 agent 里有多少仍在使用、多少已停用，演讲只说了「一部分」，没有给具体比例；158 个 Claude Code 技能里实际被使用的比例也未披露。 第七，该实践是 Forter 内部工具建设，不涉及客户现场交付，因此演讲没有覆盖跨组织边界的数据合规与责任划分。 第八，演讲通篇没有延迟、准确率、召回率等性能数字，所有收益都是流程层面的（省时间、挡提问、少返工），无法与基线做量化对比。 谁该行动、具体怎么做，可以按下面四步落地。以下四步的对象是正在客户现场推进企业 AI 落地的 FDE。 第一步，先建一个中央 MCP 服务器，不要一上来就给每个团队接厂商各自的 MCP。演讲者的判断是，大多数工具只是现有 API 的薄封装，写一个小脚本把「工具描述」与参数映射到 API 调用就够；只有当某个厂商提供六七十个端点时，才需要挑着暴露，否则 agent 会被工具淹没。 第二步，检索先别自建。若公司已有「企业搜索」（如 Glean 这类接 Confluence、Jira、Slack、Salesforce 的产品），先在它上面暴露 search、reads、summarize 三个工具，summarize 带一个 focus 参数，把自建 RAG 的切分、索引、召回、排序四项工作整体推后。 第三步，按触发方式一次给齐三种平台：「无代码」用于快速试错，代码模板用于需要定制的场景，非交互式 agent 直接复用已有「作业调度」（Forter 用的是 Argo Workflows 的 cron 与 webhook event sensor），不要为 agent 新建一套调度。 第四步，上线前先做三件事：与法务约定高风险与「低风险用例」的分界并让高风险一律走审；与安全约定冲刺期禁止访问外部网络或接收不可信输入，并把权限校验写进代码而不是「系统提示」；把每个团队的 token 消耗做成「仪表盘」并主动盯。 适用条件是三条同时成立：使用者主要在公司内部；关键决策处仍有人；公司已经有可复用的「企业搜索」和「作业调度」。三条缺任何一条，本文的取舍都要重新评估，尤其是跳过评估器这一条。 回滚与退出方式：「脚手架」若出现「新能力需要逐仓库改造」的信号，就按 Forter 的做法回退到少量大仓库、每仓库承载一组相关 agent；「无代码」平台若出现连接不稳定或缺少「版本管理」，就把该 agent 迁到代码模板仓库，保留同一套 MCP 工具配置即可，工具层不需要重建。 最后一条判断规则：这套方案的核心不是「两周」这个时间，FDE 也不必复制它的规模，而是把工具层做成单一入口、把检索外包给已有「企业搜索」、把法律与安全关切提前收敛成可执行的分界。「前置部署」Forward Deployed Engineer（FDE）拿这套结构去和客户对齐范围，比争论用哪个框架更有用。 原始来源： - https://www.infoq.com/presentations/building-internal-ai-agents/