我意外地构建了一个前向部署工程师（forward-deployed engineer）的现场工具包（field kit）

一年前，我从一个项目中删除了 @anthropic-ai/sdk，并编写了大约150行TypeScript代码来替换它。

我给自己找的理由既诚实又无聊。该SDK通过一个代理工具集模块引入了 node:fs/promises，这破坏了浏览器打包。我本可以等待一个浏览器兼容的入口点。但我却手动编写了一个SSE解析器，并写了一篇文章解释原因。

我当时把这归类为一个打包工具的故事。

然后，我读到了一篇关于前向部署工程师（forward-deployed engineers）工具的文章——这些工程师被派往客户的办公楼，以确保AI部署真正落地。大意是：每个框架依赖都会成为客户安全团队询问的对象，而裸金属代码在并非自己的环境中更容易调试。

同样的决策。同样理由。不同的学科，不同的职位，完全不同的问题——但除了它并不是一个不同的问题。

我一直在解决的并非是一个打包工具问题。我一直在解决一个部署问题，却从未给它命名，这便是我将其误认为品味问题的原因。

这篇帖子记录了我回溯自己已发布的五个工具中的每一个架构决策，并问了一个我从未问过的问题：这里真正起作用的约束是什么？

TL;DR

• 五个工具，全部仅限浏览器，全部BYOK（自带密钥），没有一个带后端。我选择了它们，感觉像是出于偏好和轻微的懒惰。
• 它们几乎完全符合在他人受监管环境中工作的约束：无需安装任何东西，数据不离开边界，安全团队无需进行威胁建模，最小化依赖面以供防御。
• 约束会趋同。两个学科解决相同形状的问题，最终会得出相同的工程决策，即便彼此从未交流。
• 对照FDE工具通常被划分的四个类别——可观测性、评估、编排、护栏——我覆盖了三个。第四个缺失了，假装它存在将是我能做的最无趣的事情。
• 可迁移的部分不是我的代码仓库。而是：一个被明确表述的约束是区分工具与玩具的关键，而大多数业余项目从未明确表述过这样一个约束。

决策及其背后的原因

这就是关于那个我当时理解错误的SDK调用的关键。

我当时的表述是：SDK在我的环境中无法工作，所以我将编写最小可行方案。合理。但我实际做的是将工具的依赖面缩减到只有 fetch 和 TextDecoder——而这一决定的后果，我甚至一次都没有考虑过，是整个运行时都是可检查的。没有任何框架在我的代码和网络之间做一些巧妙的事情。当流异常终止时，我阅读自己的解析器。

当你在自己的笔记本电脑上调试、有调试器附接且拥有充足时间时，这个特性毫无价值。

当你在与别人的工程师通话、在别人的网络中，他们询问为何响应被截断，而诚实回答需要在接下来的九十秒内到达时，这个特性就是一切。

我并非为此而构建。但它就是这样。

另外四个决策，相同的模式

一旦我开始观察，模式并没有停止。

BYOK——带上你自己的密钥。我对自己说：我不想运行代理，我不想持有任何人的凭证，我真的不想为陌生人的令牌付费。这些都属实。但实际上：客户的密钥永远不会离开他们的浏览器，他们的提示词永远不会触及我控制的基础设施。无需协商数据处理协议，因为没有数据处理。"我太懒了不想运行后端"的版本与"这通过了合规审查"的版本是同一架构。

完全没有后端。我对自己说：静态托管是免费的，我不想为业余项目维护服务器。但实际上：没有服务器需要威胁建模，没有攻击面需要记录，没有正常运行故事需要讲述，没有需要六周时间才能清除的供应商安全问卷。安全团队能最快批准的就是不存在的东西。

每个工具都是一个URL。我对自己说：共享链接比让别人克隆仓库并运行 npm install 更容易。但实际上：零安装。没有任何东西进入客户的机器。最需要诊断工具的人正是最不允许安装工具的人。

费用实时显示，而非记录在日志中。我对自己说：数字很有趣，我想看着它变动。但实际上：批准续费的人可以无需询问任何人就能阅读它。我搬出了一个关于提示缓存是最廉价且无人衡量的优化这一论点，却仍将其框定为工程卫生问题。它不是。这是一个信任问题，而信任决定了部署能否存活。

四个决策。四个我当时给出的理由，真实但浅薄。一个潜藏于所有决策之下却从未被说出口的约束。

仅限浏览器实际上付出了什么代价

我不想让这听起来比实际更干净，所以让我花点时间来反驳自己。

仅限浏览器对于很多软件来说是一个真正糟糕的选择。你没有服务器端的密钥处理。你不断与CORS作斗争——对某些提供商而言，你根本无可奈何，因为它们不发送标头，而你在标签页里无能为力。你没有值得一提的持久存储，没有定时任务，没有后台处理，没有计算密集型任务的能力。你无法这样构建产品。我不会假装你可以。

但所有这些限制对诊断工具来说都不构成约束。

一个万用表不需要数据库。告诉系统为何行为异常的工具不是系统本身。它必须可信、便携且易读——并且必须在所有更重的设备都不可用的精确时刻能够工作。我列出的每个作为代价的约束与该任务都无关，而其中两个（无存储、无服务器）正是它能在拒绝真正部署的地方被使用的理由。

限制与资格是从两个角度看待的同一事实。

地图

FDE工具被相当一致地描述为四个类别：智能体编排、评估、护栏和可观测性。我逐个将我的工具放入这些框。

| 类别 | 工具 | 功能 | | --- | --- | --- | | 可观测性 | claudoscope | 对实时调用进行X光透视——令牌组合、缓存读写、成本，在响应流传输过程中 | | 可观测性/调试 | agent-replay | 将完成的智能体追踪回放为时间线，而非一堵嵌套JSON的墙 | | 预检 | context-lens | 在发送前统计提示——窗口位置、成本、缓存边界 | | 评估 | prompt-lab | 两个提示，一个输入，并排输出，延迟和成本 | | 编排 | tool-lab | 沙盒化工具使用循环——定义工具、模拟响应、手动驱动 | | 护栏 | — | — |

覆盖了三个类别，一个预检加分项，一个空白。

我要小心，因为有一种版本的帖子是戴FDE帽子做作品集巡游，那种版本毫无价值。所以：我并没有计划这张地图。它是事后追加的。这些工具是一个个在几个周末里构建的，我当时能表述的唯一主线就是“让Claude API可读”。这些类别来自别人的学科。这个适配是真的，也是一个意外，这两者可以同时成立。

无法粉饰的空白

护栏缺失了，而那正是在现场最可能让人受伤的。

护栏是保持模型输出在代码可以安全消费的形状之内的层。你要求 {"risk": "high"|"medium"|"low", "score": 0-100}。实际返回的，经过足够多的调用：

• 包裹在Markdown围栏内的JSON
• "HIGH" 而不是 "high"——枚举漂移
• "very high"——一个不存在的枚举值，现场发明
• "score": "85" 作为字符串，静默破坏下游算术
• score 完全缺失
• JSON开始之前的一段散文

每一个要么使你的解析器崩溃，要么更糟——不崩溃，却悄悄将错误类别放在某人的仪表板上。

这需要一个工具而非单元测试的原因是失败是分布性的。你运行一次，它工作，你发布。然后四十次调用中一次返回幻觉枚举，你永远看不到它，因为你只看了一个样本。你需要的是失败率，按失败类型细分，跨五十次运行。这是一个不同于“它工作吗”的问题。

所以，这就是第六个工具，并且它是接下来应该诚实地构建的工具：定义一个模式，针对该模式运行一个提示N次，显示它出错方式的分布。与其余工具相同的约束——仅限浏览器、BYOK、无后端，因为此时这些不再是偏好，而是规范。

为什么这可以一般化

去掉我的代码仓库，只剩下一个值得保留的想法。

大多数业余项目没有约束。这就是为什么它们读起来像玩具——不是因为它们小或未完成，而是因为没有任何东西是强制性的。任何决策都可以转向另一边而不会破坏任何东西。读者能感觉到。

一个有明确约束的工具读起来完全不同，即便它只有五十行。“这个在标签页中运行，因为它必须在无法安装任何东西的地方工作”是一个设计概要。“这是一个React应用”则不是。第一个告诉你作者面对的是什么；第二个告诉你他们输入了什么。

对我来说，不舒服的部分是我一直拥有这个约束却无法命名它。我在无意识下遵循的规则下发布了五个东西，因为我从来说出口，我也无法告诉你这些工作证明了什么。它们看起来像五个小工具。但它们是一个立场。

如果你是一个前端工程师，看着当前的AI招聘市场，想知道如何使自己变得可读：你很可能已经在你的代码仓库中拥有约束形状的工作。关键不是构建新东西。而是回去弄清楚你实际上在解决什么，然后在README中说出来。

我的用了一年和一个陌生人的关于安全团队的句子。

关于企业AI最后一英里的系列的第二部分。第一部分是《没有人的模型失败了。是界面》。第三部分是关于我一直在说但尚未妥善辩护的东西——在这类工作中，交付物不是提示，而是评估。

这篇帖子转载自ferhatatagun.com/blog/accidental-fde-field-kit——那是规范URL。

来自同一处的更多内容：

欢迎在此处或规范帖子中讨论——两条线程都保持开放。