医疗保健公司 Headway：自建了一款买不到的 AI 工具

原文作者：Katie Parrott
原文日期：2026-08-21
原文链接：https://every.to/p/the-healthcare-company-that-built-the-ai-tool-it-couldn-t-buy

披露：Headway 是 Every Consulting 的客户；我们向其领导团队提供了一次付费高管 AI 工作坊。Headway 有机会核实文中细节，但对本文没有编辑控制权。

在心理健康医疗公司 Headway，一个 AI agent 可以在每一步都不必征求许可的情况下采取行动。对于一家身处严格监管行业、拥有约 900 名员工、需要处理敏感患者信息的公司来说，这听起来有些意外。但这种自主性之所以可行，是因为 Headway 对 agent 有严格控制。每一段对话都运行在一个密封、一次性使用的容器里，与公司其他工具和数据的连接被刻意限制得很窄。

这种架构支撑起了 Eddy——当市面上现有产品无法同时满足 Headway 在安全、合规和工作流程上的组合要求时，Headway 自建的内部 AI 助手。Eddy 基于 Claude Code SDK（Anthropic 为使用 Claude Code 开发产品的团队提供的工具包）构建，托管在 Headway 自己的 Amazon Web Services 环境中，并接入公司的工具和数据。

六个月前，Eddy 的开发才刚刚开始。Headway 最初想要的是一款现成产品，一度准备与一家大型 AI 厂商签约，把它家的桌面应用开放给员工使用。但首席技术官 Arnaud Ferreri 说，如果依赖供应商来交付满足 Headway 工作流程和对敏感患者数据严格合规要求的功能，“感觉我们像是错过了火车”。

团队决定自建，这正好与市场趋势相反：2025 年 11 月一项针对 495 名美国企业 AI 决策者的调查发现，76% 的 AI 用例是“购买”而非“自建”，而一年前这一比例为 53%。

但这个决定似乎正在带来回报。Ferreri 说，如今全公司每周都会使用 Eddy——900 名员工中，有 650 人每天都用——无论他们来自工程、产品、设计、数据、运营还是临床团队。自 3 月 2 日开发者提交首批代码以来，Eddy 已经运行了大约 26 万次对话。

通用 AI 产品的能力正越来越强，但它们往往满足不了组织的具体需求；如果一家公司的合规规则、数据边界和工作流程足够特殊，供应商可能无法及时适配，或者需要做出不可接受的妥协。真正的挑战在于判断：什么时候该停止等待，转为自己动手。

在安全与可用性之间取得平衡

负责为 Headway 探索 AI 选项的工作组并不想花钱训练模型，也不想在模型能力上与实验室们竞争。他们提议的是一套“约束框架”（harness）——为现有 AI 模型设计的一个自定义封装层，用于控制模型可以访问什么、可以做什么——边界按照 Headway 处理个人身份信息和受保护健康信息时的安全与合规要求来设计。

Eddy 的每段对话都在一个全新的 Docker 容器中运行，这是一个密封、用完即弃的工作空间，与 Headway 的其他系统隔离。对话结束后，容器会被销毁。

正是这个容器，让合规团队能够接受 agent 在操作时不必每一步都请用户批准。Ferreri 说：“Claude Code 可以决定抹掉整个硬盘，没关系。这只是对话的一次性容器。”当 agent 拉取敏感数据进行分析时，它处理的是副本，任务结束后副本即被清除。它只能从公司的数据仓库 Snowflake 读取，不能写入；不能直接浏览开放互联网，但可以通过严格代理使用网络搜索；也不能发送邮件。

最坏的情况是提示注入攻击（prompt injection）：恶意行为者把指令藏在 AI 被要求阅读的内容中——例如一封邮件——让它收集敏感公司数据并发送到别处。Ferreri 说，Headway 的外发策略（egress policy）就是为预防这种情况设计的：即使 agent 能访问敏感的內部数据，也不能把它发出去。

Eddy 如何走出工程部门

Ferreri 原本计划在第一周先做 10 人小范围 alpha 测试。结果到第一周结束时，有三四十个人争着要试用 Eddy。“我不得不把人往外推。”他说。

当时功能还没准备好，如果过早把 Eddy 放开，可能会损害信任。因此 Ferreri 的团队在向全公司开放时，为 Eddy 的有机扩散打下了基础——没有管理者强制员工使用。两个关键的产品决策推动了采用。

首先，Headway 添加了使用模型上下文协议（Model Context Protocol，MCP）的连接器——这是一种把 AI 应用连接到外部工具和数据的开放标准——让 Eddy 能直接使用员工已经在用的软件。Figma 连接器让 agent 能读取和编辑设计文件；Snowflake 连接器让它能查询数据仓库。

产品经理可以让 Eddy 起草产品需求文档（PRD），并让它从内部 Slack 讨论和 Google Drive 中提取上下文。数据科学家可以要求一份公司现状仪表盘，Eddy 能运行 Snowflake 查询、生成 HTML 产物，并围绕数据写出解读。

Figma 和 Snowflake 的 MCP 连接器对 Claude、Codex 这类 agent 是存在的，但大型 AI 供应商很难卖出 Headway 这样复杂公司真正需要的“定制连接器 + 权限 + 临床访问规则”组合。因为 Headway 最了解自己的数据、部门和风险，它可以把这些上下文组织成一个能满足法务与合规团队要求的连贯系统。

Eddy 的产出也推动了它的传播。渐渐地，处理患者账单调查时，人们不再把 Eddy 的回答复制到 Google Docs，因为它的 HTML 产物更丰富、更容易分享。后来，大家想像编辑文档一样在产物上留下评论，于是团队加入了行内评论功能。

这些选择让 Eddy 在 Headway 约 900 名同事这个天然受众中变得异常有黏性。Headway 后来设定了一个 AI token 使用量目标来鼓励采用，但那时，公司大多数员工已经在每天使用 Eddy。

自建的代价

自建让 Headway 得到了买不到的产品，但也让它接手了通常由供应商处理的工作：维护可用性、降低延迟、响应功能请求，以及与 AI 能力扩张保持同步。如果说第一周的问题是“把人挡住”，那么三个月后的问题就是“让 Eddy 一直跑着”。

到五月，Eddy 大约每周宕机两次，两名工程师全职负责可靠性。Ferreri 说，系统此后已经稳定下来，没有再出现重大宕机，同时团队还在以每天发布 5 到 10 个功能的速度迭代。

启动时间仍然是个问题。由于系统每次都会启动一个新容器，新开启一段 Eddy 对话大约需要 30 秒。如果任务是“去做这个功能”，agent 持续工作 20 分钟，这点等待还可以接受；但如果只是想快速问一个问题，就会让人有点烦躁。

跟上 AI 新能力是另一个挑战。因为 Eddy 有自己的界面，外部 AI 工具的新功能不会自动出现在 Headway。如果 Cursor 发布了一个新功能，Headway 就得决定：是让工程师直接用 Cursor，还是等两周、把这个功能做进 Eddy。到目前为止，自建仍然是最合理的，但每一项外部创新都会迫使团队重新考虑：内部版本是否还值得维护。

另一个“令人欢迎的问题”是功能需求越来越多。工程团队想要更好的 Git 集成，产品经理想要更丰富的 PRD 模板，临床团队则需要特殊的数据边界。

每个需求单独看都合理，但 Ferreri 说：“我不想让它变成一棵圣诞树——每个功能都挂上去，最后反而看起来什么都不是。能做不代表应该做。”

到目前为止，Headway 选择自己承担构建和维护 Eddy 的成本。如果想做出同样的选择，就需要为这个产品配置专门人手、自己承担可靠性、在稳定性和功能请求之间做取舍，并不断决定是否要复刻外部供应商发布的功能。Headway 成了自己的 AI 供应商，也随之承担了相应的维护负担。

什么时候该等、该买、该自建

不是每家公司都需要自己的 Eddy。自建成本高、需要持续投入，而且容易做错。Every 的技术咨询负责人 Mike Taylor 说，大多数公司都不应该这样自建内部 AI 工具：“如果能用现成软件解决问题，就省下维护成本，也别去承担猜错的风险。但如果把在 AI 上领先于市场作为战略核心，有时候就得卷起袖子，把缺失的东西造出来。”

这个决定取决于：约束到底是什么；供应商有多大可能很快补齐差距；公司在等待期间会损失什么；以及它是否准备好为自己创造出来的东西负责。Headway 的经验给出了一个三部分框架：

  • 等待：当缺失的能力很可能很快就会到来，且等待的代价低于自建并维护一个替代品的代价时。
  • 购买：当供应商能够在不让公司放弃某种战略重要事项的前提下，满足公司对安全、数据和工作流程的要求时。
  • 自建：当约束是长期存在、不常见、且足够重要，以至于公司愿意无限期地承担可靠性、安全、培训和产品决策的责任时。

对于那些决定自建的公司，Ferreri 的建议是：

  • 找到离 AI 前沿最近的三四名工程师，给他们一个季度去探索，而不是一张固定路线图。
  • 让这个小组有一位执行发起人，并尽早让法务、合规和安全团队参与进来，确定产品能访问什么、能做什么。但不要给这个小组在真空中不受约束的自由。
  • 只有等团队建立了安全权限边界和可复用的架构后，再扩大使用范围。先做工程部门试点可能是更稳妥的起点。Eddy 能扩散，是因为 Headway 最终让 Eddy 的连接器、权限和产物在工程部门以外也有用，而不是第一天就让每个部门拿到一个没有限制的版本。
  • 把 AI 原生的构建者和其他人连接起来。管理、文档、培训、示例和内部推广，对持久采用仍然很重要。

Headway 的技术栈在功能复杂度上并不比市面上买得到的产品更高。Eddy 的优势在于它的安全配置、与 Headway 系统的连接，以及一个针对该公司而非供应商其他一万名客户量身定制的产品规划。等供应商把这些拼在一起，对 Headway 来说，成本可能比自建 Eddy 更高。其他公司也需要自己决定：那款买不到的工具，是否值得自己建造——并且持续维护。

本文作者 Katie Parrott 是 Every 的撰稿人，更多作品见她的 newsletter。

核心启示：当现成 AI 供应商无法满足一家公司独特的安全、合规与工作流约束时，自建可能是更务实的选择；但这意味着成为自己的 AI 供应商，并要愿意长期承担可靠性、安全、迭代和产品维护成本。Headway 的判断框架是：能等就等、能买就买，只有约束长期、独特且足够重要时才自建。

《The Healthcare Company That Built the AI Tool It Couldn’t Buy》的发芽报告

材料核心

心理健康医疗公司 Headway（约 900 人）在市场上买不到同时满足“安全 + 合规 + 工作流”的 AI 产品后，用 Anthropic 的 Claude Code SDK 在自己的 AWS 环境里自建了内部 AI 助手 Eddy：每次对话都在一个全新的一次性 Docker 容器中运行，容器随对话结束而销毁，agent 因而可以“每一步都不请求许可”地自主行动。自 3 月 2 日写下第一行代码以来，Eddy 已运行约 26 万次对话，650/900 名员工每天使用。文章借此给出“等待 / 购买 / 自建”的判断框架，并展示自建 AI 治理工具的真实代价：维护可靠性、追赶新能力、抵御“圣诞树式”功能膨胀。

发芽 01：不造大脑，造笼子

种子

市场主流是“买”：Menlo Ventures 2025 年 11 月对 495 位企业 AI 决策者的调查显示，76% 的 AI 用例来自采购，而一年前只有 53%。Headway 却选择了“建”。但仔细看 Headway 建的是什么：不是模型，不是通用产品，而是一个 harness——一个控制模型可以访问什么、可以做什么的“笼子”。Ferreri 的团队从一开始就明确：“不想花钱训练模型，也不想和实验室比拼能力。”当模型能力变成商品，真正值得自建的，不是“智能”，而是“边界”。

故事

这恰好能对照英国国民医疗系统（NHS）史上最著名的 IT 失败。2002 年，英国启动“国家 IT 计划”（NPfIT），试图为整个 NHS 建设全国统一的电子病历系统，由少数几家大型承包商（CSC、BT、Accenture、富士通）承担，2006 年英国国家审计署（NAO）对十年总成本的估计已达约 124 亿英镑。2011 年，该计划被拆解，大量模块从未交付或最终废弃。NHS 和 Headway 其实面临同一个问题：市售产品无法匹配组织的合规与工作流。但 NHS 选择的“建”是系统层面的巨型集成——在全国标准、供应商协调和数万个流程之间做一个“系统的系统”；而 Headway 选择的“建”只是一层为组织自己定制的薄边界：一次性容器、只读 Snowflake、严格出口策略、MCP 连接器。文章里那句容易被忽略的话正是全篇钥匙：“Headway 的 stack 并不比市售产品功能更复杂；Eddy 的优势在于安全设置、与 Headway 系统的连接，以及一个为这家公司而不是为 vendor 其他 10,000 个客户定制的产品计划。”NPfIT 的教训不是“不该自建”，而是“建错了层级”——当模型成为快速演进的大宗商品时，把整个行业的标准、流程和长期合同同时装进一个系统，是最昂贵也最脆弱的选择。

Aha 瞬间

“当模型变成商品，build 的单元不应是大脑，而是笼子。NHS 想拥有系统，Headway 只想拥有边界；后者是六个月内能跑起来的那种建，前者是十二年也推不平的那种建。”

发芽 02：缩小爆炸半径，胜过硬编码许可

种子

文章最反直觉的一段长这样：Headway 的 AI agent “可以每一步都不请求许可地行动”——在合规极严、处理敏感患者数据的行业里，这听起来像事故。但许可不是被信任取代了，而是被“丢弃性”取代了。Ferreri 的说法更直白：“Claude Code 可以把整个硬盘擦掉。没关系。这不过是一次对话的一次性容器。”传统安全逻辑是：越重要的事，越要审批。Headway 的安全逻辑是：把最坏情况的爆炸半径缩小到不值得审批。

故事

这其实是航天领域的标准做法。火箭每次发射前，地面安全官并不是靠“火箭一定不会错”来保证安全，而是确认火箭装有一套“飞行终止系统”（Flight Termination System，FTS）：一旦火箭偏离安全走廊或出现致命异常，地面可发出指令在空中引爆它。正因为最坏结果被预先“收口”，发射才可能穿越人口密集区域。Headway 的出口策略就是数据世界的 FTS：即使攻击者通过提示注入骗过了 agent，即使 agent 已经把敏感数据握在手里，egress policy 也让它无法把数据送出网络。安全工程里著名的“爆炸半径（blast radius）”概念讲的正是这件事：不要试图让失败不发生，而要保证失败发生的范围可控。计算史上还有一句常被归于 Grace Hopper 的管理格言：“It’s easier to ask forgiveness than permission。”放在 agentic AI 语境里，Headway 把它翻译成了一个工程设计：不是靠事后道歉，而是从架构上允许失败——只要失败可以被销毁、不扩散、带不走数据。

Aha 瞬间

“要赋予 AI 代理真正的自主，不需要提高对它的信任，只需要缩小它搞砸的爆炸半径。当最坏结果已经小到可以被一键丢弃，审批从安全机制变成了纯粹的减速带。”

发芽 03：修剪自己的圣诞树——自建让你成为自己的 AI 供应商

种子

文章后半部分没有回避自建的代价：Headway 接手了原本 vendor 该干的活——保证可用性、控制延迟、响应需求、追赶前沿能力。到五月，Eddy 大约每周宕机两次，两位工程师全职做稳定性；新对话启动要约 30 秒；团队每天还持续上线 5–10 个功能。比宕机更危险的是需求的引力：工程要更好的 Git 集成，产品经理要更丰富的 PRD 模板，临床团队要特殊的数据边界。Ferreri 的回应是那句更值得记住的话：“我不希望这变成一棵圣诞树，什么功能都挂上去，最后看起来什么都不是。Just because you can doesn’t mean you should.”

故事

软件工程最古老的诅咒之一，早在 1975 年就被 Frederick Brooks 在《人月神话》（The Mythical Man-Month）里命名了：第二系统效应（second-system effect）。Brooks 从 IBM System/360 的开发中观察到，设计师建造第二个系统时最危险——因为在第一个系统里被压制下来的所有“好主意”都会涌进第二个系统，结果是过度设计、功能膨胀、失去重心。Eddy 严格说现在还是“第一个系统”，但它正以极快的速度被同事们变成“所有人的第二系统”：每个部门都想要一个“也只是合理”的新功能。区别在于，外部 vendor 的圣诞树是由 10,000 家客户的诉求共同长成的；内部平台一旦失控，圣诞树是由 900 位同事的热情长成的。文章说 Headway 成了“自己的 AI vendor”。这意味着“vendor lock-in”并没有消失，它被搬进了公司内部：外部 vendor 替你完成“对 10,000 个客户说不”的艰难工作；自建之后，“对 900 个同事说不”变成了你自己的产品治理能力。

Aha 瞬间

“自建 AI 工具没有消灭 vendor lock-in，只是把决策权还给了你——连同拒绝的债。能帮你抵挡功能膨胀的，不再是 vendor 的产品路线图，而是你自己是否愿意持续修剪那棵圣诞树。”

你的思考空间

  • 当 AI 的价值从“模型能力”转移到“边界与上下文”时，你的组织拥有哪些独特的数据、流程和合规约束，足以构成比 vendor 更快、更准的“建”的理由？
  • 你的系统里，有几套真正的一次性容器、只读数据源和出口限制？还是仍然在靠“不断审批”来假装实现了安全？
  • 如果 Eddy 正好是你们候选架构的样子，你会用什么硬机制来对抗第二系统效应——比如每季度强制删功能、新功能必须砍掉一个旧功能、或者按“能否在 30 秒内解释价值”来投票？
  • 当外部 AI 工具每几周就发布一个新能力时，该怎么判断“等它成熟”还是“自己在内部平台里再造一遍”？文章的框架是：等待的代价 vs 自建维护的代价，以及核心痛点是否与战略直接相关。
  • Eddy 的扩散靠的是“有人做出了比 Google Docs 更好分享的 HTML artifact”，而不是高管下令。你的内部 AI 工具是否也设计了能让人自发共享、评论和复用的输出物？如果没有，强制打卡式的采用率很快就会见顶。