返回资讯中心
外部精选
软件工程
#开发者实时流

AI代理不访问代码库,仅凭登录账号自动编写帮助中心文档

来源标题:How Our AI Agents Write a Help Center

一家公司开发的AI代理系统只需获取产品网址和登录账号,就能像新员工一样操作产品并自动生成包含图文指南、截图和短视频的帮助中心。该系统不要求访问源码仓库,规避了企业对代码外泄的安全顾虑。其架构已从单一代理演变为由多个小代理组成的七阶段流水线。

Hacker News 最新_aravindc2026/11/3 · 4 天前22 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

一个agent如何演变成由小型agent组成的七阶段流水线,以及每次拆分背后的工程考量。

每家软件公司都有同样的问题:帮助中心总是落后于产品。界面变了,按钮挪了,新功能上线了,而文档还在描述上个季度的应用。

大多数“AI文档”工具从代码出发:接入你的代码仓库,然后读取它。实际上,很多合作谈到这里就结束了。公司不愿意把源代码交给外部供应商,理由很充分:安全审查、知识产权、合同,或者干脆就是一条政策——代码仓库永远不出公司大门。

但每家想要帮助中心的公司,本来就会给新员工、QA测试人员和培训师开登录账号。所以我们换了个问题:如果一个系统像新员工那样去使用产品,并根据它看到的内容来写帮助中心,会怎样?不需要代码仓库权限,只要一个登录账号。

事实证明,这也更贴近读者的需求。审批当日现金的门店经理,或者收货的采购员,从来不看代码。他们需要知道的东西,都在界面上。

给它一个网址和一个登录账号,它就能交付一个帮助中心:书面指南、截图和短视频。

最开始它只是一个agent。现在它是一条七阶段的流水线。下面是它如何走到这一步的故事。

我们的第一个版本很简单。给一个agent配一个浏览器,让它探索产品并撰写文档。

对于小型应用,这几乎可行。但对于真正的企业级产品——几十个功能区域、数百个界面——它在两个方面出了问题。

第一是成本。agent看过的每个界面都进入它的记忆,它写过的每一页也一样。而且每走一步,它都要把所有这些重新读一遍。所以账单不只是随运行时间增长,而是增长得快得多。当记忆填满时,agent开始压缩自己的笔记来腾出空间。它最先丢掉的东西,恰恰是帮助文章最需要的:确切的按钮名称、步骤的顺序、状态名称。

第二是覆盖范围。agent自己决定去哪里。它在某些区域花了大量时间,对另一些区域 barely 看一眼,空间用完就停了。我们没有任何清单可以对照,所以甚至无法判断它漏掉了什么。

两个问题有同一个解法:不要让一个agent既探索又写作。我们把探索变成独立的步骤。

研究agent登录后,按照一份清单逐个区域地浏览产品。在每个界面上它做笔记,我们称之为map:界面上有什么、每个按钮做什么、尝试操作时发生了什么。它还写一份简短的业务摘要:谁在使用产品,哪些任务对他们最重要。

探索主要是点来点去、阅读和记录。工作量很大,但都不难,所以研究环节跑在Haiku上——一个小而便宜的模型。而且因为它按清单工作,我们终于可以检查有没有遗漏。

map后来成了整个系统中最重要的部分。这一步之后的所有环节都必须严格遵循它。map里没写的,文档里就不会写。

有了研究结果之后,我们试着让Haiku也来写页面。成本低,但页面质量不够好。一个好的帮助页面意味着要挑出重点、把步骤排对顺序、向非技术读者解释清楚。这需要判断力,小模型不够用。

于是我们把写作切换到了Sonnet。我们学到了一个反复印证的道理:探索和写作需要不同的能力,不必两者都付最高的价钱。

然后成本问题又回来了。一个Sonnet写手负责整个站点,就得把所有map和已经写好的每一页都记在脑子里。页面越多,负担越重,账单也越高。

所以我们再次拆分。首先,规划器只读一次研究结果,然后决定主题:每个页面、放在哪个章节、按什么顺序。每个页面覆盖用户完成的一项任务,比如“取消订单”,而不是一个界面,比如“订单界面”。我们先用Haiku做规划,结果规划质量很差。规划整个站点需要判断力,所以规划器也用Sonnet。

主题确定后,我们为每个页面启动一个写手,全部同时进行。每个写手只拿到自己的主题和该页面所用界面的笔记。无论产品多大,单个写手的工作量都保持不变,所以成本随页面数量增长,而不会增长得更快。而且因为页面之间互不依赖,起草耗时大约等于最慢的那一页,而不是所有页面加起来。

按任务规划也解决了一个写作问题。当写手直接根据界面笔记写作时,他们会写出我们开始称之为“界面腔”的东西:把界面上所有东西巡览一遍,而不是帮助用户完成一件事。给写手一个任务而不是一个界面,页面就会按读者的思维方式来写。

AI写手会用听起来合理的猜测来填补空白,比如按钮写的是Submit,它却写“点击Save”。而写手检查自己的页面,只会自己同意自己。

所以由一个独立的编辑来审查每个页面。它保持风格一致,并删掉任何无法追溯到map的说法。

但“正确”的标准因企业而异。银行想要正式的语气,永远不说“just”。零售应用称其为“stores”而不是“locations”。一个团队希望每个页面开头先说明面向谁,另一个团队希望直接进入步骤。有些术语绝不能出现在公开文档中。没有一套规则适合所有人。

所以编辑的规则放在一个SKILL.md里。我们提供一个合理的默认值,每个团队可以改成自己的。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →