我们自建了一款智能体原生工具，它彻底改变了我们构建软件的方式

原文：https://every.to/p/we-built-our-own-agent-native-tool-it-overhauled-how-we-build-software 作者：Stella Garber 日期：2026-06-16

那是周一早上，我的联合创始人 Brian 正在读我们智能体（agent）输出的客户发现通话周报分析。“订阅留存，”他念道，“五家不同的品牌都把它列为头等大事，但没有一家相信现有的 AI 工具能碰这块。”

仅仅几周前，想挖掘出这样的洞察几乎是不可能的。

我在一家尚未达成产品-市场契合（product-market fit）的创业公司。我们所有人都在跟潜在客户沟通，试图为产品找到定位，但要追踪所有学到的信息却是一团乱麻——创始人不同、平台各异、媒介混杂，记录散落各处。为了能在周一例会上分享我们学到的东西，Brian 得从 Slack 里翻笔记，从 Granola 里扒转写文本，再丢进 Claude Code 里试图理出头绪。

我们承担不起这个级别的混乱。我们刚刚推出了 Hoop ——一个帮助订阅制品牌降低流失的智能体。我们必须尽可能快地学习，这意味着我们需要尽可能多地跟潜在客户沟通，然后严格记录并给每一通电话打分，从而区分出“客气的兴趣”和“真实的需求”。团队总共五个人，所有人都付出了努力，但每个人都有自己的流程、自己的工具，也有自己对每次通话中发生了什么的解读。

于是，我和我的两位联合创始人——我们三个人中没有任何一位头衔里有“工程师”三个字——动手做了一个内部工具来解决这个问题。但我们没想到的是，这个工具也彻底改变了我们为客户构建实际产品的方式。

“我应该为这件事造个东西”

我们的周一例会之所以那么没有章法，是因为客户通话的信息分散在不同地方，这取决于谁接了电话，以及他们用的是 Granola 还是其他转写工具。我们完全没有办法看清模式，从而得出“潜在客户到底想要什么”的结论。

我的另一位联合创始人、团队里的产品专家 Justin，利用几天里的零碎时间，总共花了不到 10 小时就搭出了第一版工具，把那些零散的通话记录集中到了一起。

这个工具的工作原理是：上传一个 Zoom 的转写文本，它会通过四到五个预先设定好的提示词（prompt）对文本进行处理，然后输出一份结构化分析，并根据 PULL 框架 进行评分。PULL 框架源自哈佛商学院，专门用来帮助早期创业公司找到产品-市场契合。同时，这个工具还会把某个潜在客户的所有对话整合成一份简报，让你看到一个客户关系的完整演变过程，而不是仅仅停留在某一次电话记录的切片里。比起在笔记和转写文本里翻来翻去，这个工具给我们提供的是以周为单位的整合性分析，帮助我们看到什么在奏效，什么没有。

Justin 搭建这条应用时，用的是一批自己此前没用过的工具：Next.js 框架 搭配 ShadCN 组件 做用户界面，Supabase 作为数据库来汇总所有笔记，然后用 Claude 的 API 来完成分析。

对 Justin 来说，他虽然学过计算机科学，但已经不常写代码了，这是一次难得的“重操旧业”的机会，也让他能在 AI 原生编程中建立信心。他从设计和构建视觉界面开始——主要是因为他就是那种“就算功能正常，但界面不顺眼也会让他格外烦躁”的人。他确保工具的外观和质感跟我们的品牌相匹配，先把组件（按钮、标签、菜单）全都打磨得干干净净，然后才开始触及数据层面。

直到搞定界面，他才直接扑向数据。他必须确保这个工具对客户对话的分析质量，比大家各自在 Claude 里手工操作产出的结果要更优。否则，我们永远不可能说服全团队都用同一个工具。所以他专门编写了一个提示词，反复手动检查输出结果，同时严格对照 Anthropic 针对 Claude 的提示词工程最佳实践，对提示词进行微调打磨。

摩擦还是太大

工具的第一版确实产出了高质量的分析，但流程里仍然有太多环节需要手动完成。比如，你得先从 Zoom 把通话转写文本下载下来，手动上传到这个工具上，填上客户名称和通话类型，然后等上好几分钟的处理时间。最后再生成一个链接，把分析结果分享到 Slack 里。

团队可以在工具里搜索转写文本和分析结果，但返回的结果质量很差。举个例子，我曾尝试搜索“对 AI 客服工具有糟糕体验的潜在客户”，却什么结果都没得到——尽管我知道，有个客户体验负责人在电话里花了整整五分钟，详细描述了他们的 AI 向顾客发送了不符合品牌调性的回复，让他们感到多么尴尬。这个工具当时只能匹配查询里的精确词语，而无法捕捉词语背后的含义。

再加上一个经典的“工具采纳”问题，我们在之前任职的生产力工具 Trello 公司对此再熟悉不过了。Justin 的工具又成了一个团队成员需要额外记着去访问的新地方，不得不与 Slack 和 Notion 争夺大家的注意力。

转向智能体原生（agent-native）

然后，我们找到了困境的答案。Justin 一直在读 Every 上关于 智能体原生架构 的文章。核心思想是，与其把一连串提示词硬编码成一个固定执行顺序的流水线，不如给模型一套工具，让它自行推理如何使用它们。而且，与其开发一个需要用户主动访问的目的地型应用，不如把工具带到人们已经在使用的工作环境中去，比如 Slack。

Justin 把那篇文章的链接丢给 Claude Code，并说明他希望构建一个符合那套架构原则的系统。这个智能体需要配备两个工具：一个用来上传并读取转写文本，另一个用来添加和编辑合作伙伴档案。有了这些，用户只需要做一件事：在 Slack 里把转写文本发给那款应用。智能体随后会确认合作伙伴名称和通话细节，接着上传转写文本、运行分析、生成摘要页面，最后发布到我们的用户反馈频道里。

Justin 开始把所有正在构建的东西都对照那套智能体原生架构指南来检查，而不仅仅是那个找产品-市场契合的具。他会带着 Claude Code 进入规划模式，列出新功能的构想，然后把它和那篇 Every 的文章一起丢回给 Claude Code，追问：“这个方案里，哪些地方与架构原则对齐了，哪些地方没对齐？”

当然，有时候他也会背离指南，前提是他判断用户在某项具体任务上根本不需要 AI 介入。比如，这个工具会追踪统计大语言模型（LLM）的 token 用量和费用——这是很有用的信息，但并非用户需要直接查询的东西。如果把这个能力暴露给智能体，只会造成不必要的困惑。

轮到我跟代码打交道了

我碰到的是另一个问题。我需要一眼就能看清整个销售漏斗管线——谁需要跟进，每段对话处于什么阶段——按照人和阶段来组织，而不仅仅是按时间排序的通话记录。

我打开了 Ghostty（一款简洁的终端应用），把工具的代码拉了下来以便在笔记本上本地运行，然后——手指因为想到要直接编辑代码而有些微微发抖——我启动了 Claude Code。

我要求 Claude Code 做的第一件事，是构建一个轻量级的数据视图，好让我能一眼看清楚管线的不同阶段。很讽刺的是，我居然是在让 Claude Code 去造一个类似 Trello 看板的东西来管理这些信息，这样就可以像移动卡片一样把代表通话的记录拖来拖去。老习惯真是顽固。

我开始以渐进增量的方式构建。我注意到，如果能在每张卡片正面标注出这笔交易的当前状态会很有用。于是我对 Claude Code 下指令：“确保每张卡片都有一条一行字的摘要，这样我一眼就能知道现在的进展如何。”部署之后，所有进到管线里的交易都会带着状态来了。每当我想做出什么调整，我只需要开口就行。

在 Justin 的鼓励下，我开始直接往共享代码仓库合并代码。有时候会把东西搞崩，但没人因此受到责备，因为搞砸的成本很低，而且大家都默认这是极其正常的事。

Brian 在晚上十点学会了智能体原生

下一个上阵的是 Brian，我们的另一位联合创始人，他负责我们每周的用户学习报告。在有了新工具之前，他常常会忘记这件事，结果就是临时去翻 Notion，或者凭记忆拿脑子里最新鲜的几次对话来即兴发挥。我们的学习成果严重偏向“近期”，而非“重要”，错失了那些只有把所有通话放在一起看时才能浮现出来的模式。

于是，Brian 构建了一个功能来自动生成这份报告。他的第一个版本是一个放在他电脑上的链接，点击后会吐出一个 Markdown 文件，他再把这个文件粘贴到 Notion 里——这个方案能用，但只有他自己能用。他的第二个版本在工具里加上了一个“学习成果”标签页，里面有一个按钮可以生成同样的 Markdown 输出，如此一来，任何人都能拉出一份报告了。

可及性的问题解决了，新问题又出现了。团队成员如果没有 Brian 本人去修改代码，就没办法调整报告的格式或侧重点。Brian 想让报告的提示词变得可编辑，这样团队不用改代码也能调优报告内容。晚上 9:25，Justin 在 Slack 里给出了建议：“你应该把提示词做成一个可编辑字段，然后把它传给智能体。”

Brian 一开始没弄明白是什么意思，于是他把 Justin 的消息复制粘贴进 Claude，请求一个解释。Claude 带他走了一遍智能体原生架构的哲学，Brian 开始渐渐懂了：与其给人类一个文本框去编辑提示词，不如给智能体一个工具，让它自己读取和修改提示词。这样一来，任何人都可以在 Slack 里直接跟工具对话，告诉它自己要改什么。

到了晚上 11:15，Brian 把这个功能跑通了。他做的测试是：让 Slack 里的智能体用克林贡语重写“学习成果”的提示词，结果真的——所有的报告都变成了克林贡语。整个过程，从零开始到搞定，只花了两个小时。

更实际的是，最近一份报告里标记出一个现象：我们最近六通电话里有四通都提到了同一个痛点——品牌正在流失那些压根没意识到自己当初订阅了服务的用户。顾客往往是为了解锁某个折扣价才订阅的，然后就忘了这是一笔持续性的扣款，当扣款发生时才惊讶地取消——而这恰恰是我们的产品可以介入的时刻，可以提供一个省钱方案或更合适的推荐。我们四个人中没有一个人曾靠自己把所有这些点串联起来；这个洞察只有当工具同时横跨分析所有通话时才浮现出来。

然后，一件出乎意料的事发生了。学习成果标签页里冒出了重复记录，Brian 在 Slack 里跟机器人提了一句。这个机器人分别查看了两条记录，判断出其中一条是空的，然后就把它删掉了——相当于自动完成了一个“查找并删除重复项”的功能。Brian 此前已经给了这个智能体对数据库的编辑权限，而模型自行推理并解决了问题。就在那一刻，Brian 豁然开朗：如果你给一个推理模型配备了一些简单但强大的工具，它就能处理那些你从来没想过、也从没为其编写过代码的状况。

我们带回产品中的东西

这个工具做的最重要的一件事，是改变了我们构建外部产品的⽅式。Justin 把他在内部验证过的智能体原生模式拿了出来，构建了多个销售工具，其中包括一个客服帮助台（helpdesk）审计工具，在潜在客户签约之前，我们就可以用它来展示 Hoop 的价值。

Brian 从构建一个“学习成果”标签页，进一步发展到构建出一个类似内部销售智能体的东西——一个我们在 Slack 里昵称为“Benny”的机器人，它能接入我们的销售工具，按指令执行任务：评估潜在客户线索质量，对照我们的理想客户画像打分，并在我们的 CRM 工具 Attio 中更新信息。而我，也从“给客户关系管理工具做功能”发展为对产品架构有了自己成熟且自信的判断。

这个工具还让我们保持了对自己诚实。当每一通电话都被自动打分和汇总总结时，你无法逃避数据告诉你的事实。当一周内有五个不同的运营方都告诉我们“你们的定价毫无逻辑”时，我们必须直面事实，并调整定价来争取拿下更多交易。如果是在一家大公司，这大概会有一支分析师团队基于这些数据来写季度报告。而我们只有五个人，靠一个自己做的工具，每周完成这一切。

再过一个月，这个工具很可能又会面目一新，这没关系。我们在这个过程中获得的那份自如感才更重要：知道什么时候该让模型配上一套工具，什么时候该老老实实硬编码一段工作流；习惯了快速交付以及接受失败——然后，再来一次。

核心启示：在 AI 时代，团队通过自建智能体原生内部工具来系统性捕获和整合客户洞察，不仅能极低成本地解决内部信息混乱的问题，更关键的是，它迫使团队直面数据中客观浮现的模式，并最终反向重塑了外部产品的构建方式——其本质是将“推理权”从固定代码转移给能够运用工具的模型，让小团队也能拥有超越其规模的学习与行动速度。