从个人 AI 工具到团队协作：一个小团队的 Agent Native 实践

案例已省略内部编号与环境标识。

从 2026 年 5 月起，我以技术顾问的身份参与一个 AI 硬件产品团队，提供 AI Agent 和服务器端技术支持。团队有四位成员：Android、iOS 开发各一位，一位产品经理兼市场负责人，以及一位测试。

最初，开发者各自在电脑上使用 Codex 等编码工具。但设备故障调查、修复后的版本核对和测试反馈，仍需要有人翻日志、查 GitHub、跟进群里的消息。

我们把 Holon 部署到服务器，让共享 Agent 持续负责调查、审阅、运维和验收跟进。开发者照常使用自己的编码工具，共享 Agent 负责跟进团队内的调查结果、修复进展和验收反馈。下面记录两个具体案例。

什么是 Agent Native 组织

业界已经开始从“给员工配 AI 助手”讨论到“人和 Agent 怎样组成团队”。微软在 2025 年的 Work Trend Index 报告中，用 Frontier Firm 描述一种新的组织形态：人和 Agent 混合协作，团队更多围绕目标组织工作，而不只按职能划分。¹

在这个小团队里，我使用一个更具体的定义：Agent Native 组织是在安排职责、工作入口和交接方式时，就把 Agent 纳入团队，让它承担明确的工作角色。

以故障调查为例。如果每次都要由开发者找到日志、粘贴到聊天窗口，再问“帮我分析一下”，AI 仍然主要是个人工具。把这项工作交给团队中的调查 Agent，就要进一步回答：新日志从哪里来？什么事件会通知它？它可以访问哪些材料？分析完写到哪里，又由谁接手？

具体到日常工作，需要安排好几件事：

• 有持续负责的事。 调查 Agent 负责把现场整理成可调查的问题，测试 Agent 负责跟进修复后的验证；一次对话结束，不代表这段职责结束。
• 使用团队共有的工作记录。 Agent 从日志事件、GitHub Issue、代码变更和部署结果接到工作，把产出写回团队已有的记录，而不是只留在某个人的聊天窗口里。
• 能把工作交给人，也能接回反馈。 需要真机操作时交给测试，需要产品判断时交给产品经理；人给出结果后，Agent 继续更新这项工作。

例如，测试 Agent 负责版本核对和接口检查，测试人员判断真实设备上的交互和体验，两者共同完成验收。

Holon 在团队里承担哪些工作

服务器端的 Holon 是这些共享 Agent 的运行环境，不替代开发者本地的编码工具。它们参与的是产品研发，与产品提供给用户的 AI 功能不同。

团队目前使用的共享角色包括：

这六个角色的模型用量记录，可以追溯到 2026 年 6 月 25 日。统计到 9 月 9 日，共 77 天，留存记录中的累计用量约为 77.64 亿 Token：输入 76.94 亿，输出 0.70 亿。输入包含缓存读取和缓存写入，其中缓存读取约 62.59 亿，已经计入总量。²

饼图展示六类角色在整个统计窗口内的累计用量占比。数值各自四舍五入，显示值相加可能与总量略有差异。

这 77 天里，每天都有共享 Agent 的运行记录。模型用量主要集中在代码审阅、现场调查和测试验收上，其他角色则按需求参与。

在同一统计窗口内，我们还整理了产品主仓库里共享 Bot 留下的记录。按实际报告或审阅的发布时间筛选，再按 Issue、PR 去重，得到以下覆盖数：³

验收记录包括代码检查、人工结果汇总和待复测结论。同一事项可以出现在多类记录中，表中数量不相加。

案例一：从设备现场到开发可以接手的 GitHub Issue

先解决“当时究竟发生了什么”

客户端设备上的 bug，难点常常不是描述现象，而是还原现场。用户看到的是“点了没反应”，开发者却需要知道：此前执行了什么操作，客户端和服务器分别走到了哪里，哪一步开始没有结果。

为此，我们建立了 trace 日志汇报机制，用一次运行过程中的事件记录，把用户操作和系统响应串起来，供开发回看现场。

按我们目前的流程，新日志上报后，通过 webhook 通知 Holon 中的调查 Agent。Agent 在服务器环境中可以直接读取获准访问的 trace，分析后创建或补充 GitHub Issue，打标签、分配开发者。已有 Issue 的调查结果会补回原记录，避免开发者还要去另一处找分析。

对团队而言，这里少了一次需要人主动发起的交接：不用等某位开发者有空，先下载日志，再喂给自己的 AI 工具。调查可以从现场材料到达时开始，结果留在大家原本就使用的 GitHub Issue 里。

一次“查看完整曲谱”无响应的调查

有一次，用户在 Android 课堂中练完一首歌，点击“看看完整曲谱”，界面没有继续。用户无法判断是在加载，还是已经卡住。

这条 Issue 带有诊断上报线索。调查 Agent 分析运行记录后，指出客户端操作长时间没有进展，取消后也缺少可见反馈。

开发接手时，面对的就不只是“按钮没反应”。Issue 中已经有了原始场景、运行线索，以及值得继续检查的取消与恢复路径。开发随后调整了 Android 的旧操作取消与重试恢复逻辑。

案例二：Issue 关闭了，谁来跟进发布后的验收？

在我们的开发流程里，关联的 GitHub Issue 会随着 PR 合并而关闭。但这时服务器尚未部署，客户端也尚未发包。Issue 列表里的工作已经结束，测试人员能拿到的版本却还不包含修复。Issue 关闭，不等于已部署、已发包，更不等于验收通过。

这段间隔可能跨过多次合并，积累一批已关闭但尚未验证的问题。测试 Agent 要持续跟进这些工作，监听服务器部署完成和客户端版本发布事件，在相应版本可测后继续验收。运维 Agent 按安排或人工要求推进部署，测试 Agent 继续核对版本与修复。

验收以一个版本周期内实际交付的变更为范围。部署或发布事件到来后，测试 Agent 核对这个版本包含哪些改动，关联其中已关闭的 Issue，再整理版本验收清单。不能只按 Issue 的关闭日期归集：已经合并、却尚未进入本次可测版本的修复，仍要留在待验收工作中。

服务器改动等对应部署，客户端改动等对应版本发布；跨端问题核对两端条件。不是每项验收都要同时等两个事件。

清单确定后，再区分哪些项目可以由 Agent 检查，哪些需要人在设备上操作。下面用两个独立案例说明这两种验证方式。

后台跳转，由 Agent 检查请求与响应

一次服务器端修复涉及管理后台跳转：访问旧地址时，跳转后的地址丢掉了查询参数。例如，原本用于指定返回位置的信息没有随跳转保留下来。

这类问题可以直接检查请求与响应，不依赖手机屏幕或硬件操作。测试 Agent 的记录显示，它在测试环境检查了四种访问情形：登录路径带参数、根路径带编码参数、子路径带多个参数，以及不带参数的路径。记录的结果是跳转地址正确保留了应有参数，并据此更新验收状态。

Agent 把这四种请求的条件和结果写回 GitHub Issue，开发与测试可以直接查看。⁴

琴键能不能发声，要到真机上确认

另一次问题发生在与 Android App 配合使用的琴上。升级固件后，进入课堂，琴键上的引导灯可以正常亮起，但人按下亮灯的琴键，却听不到琴声。旧固件没有这个现象。

开发排查后发现，Android 在连接设备时发送了互相冲突的模式指令。新固件按其中一种模式处理按键，导致按下琴键不再直接发出单音。修复移除了多余指令，并补上回归测试，防止它们再次进入连接流程。

代码测试可以检查“有没有发出不该发的指令”，却不能替人确认琴键按下后是否真的有声音。团队成员在对应的新固件设备上，使用修复后的 Android 包，重走了连接设备、进入课堂、琴键亮灯、按键发声和课堂交互的路径。开发把这份真机确认连同复测版本写回 GitHub Issue。

测试 Agent 接手时，这次人工实测已经完成。它核对修复改动与 CI 结果，再把代码检查、CI 结果和已有的真机反馈汇总到验收记录中。开发不必等 Agent 分配才开始调试，Agent 也不必要求人把已经做过的验证再做一遍。

如果还没有真机反馈，测试 Agent 就把设备条件、可测试版本和复测步骤交给测试人员，等实测完成后再更新验收记录。

从各自使用 AI，到共同推进一件事

回看这两个案例，共享 Agent 承担的是团队交接中需要持续跟进的工作：现场日志到达后，整理成开发可以接手的问题；代码合并后，继续等待部署和发包，把自动检查与人工实测汇总到验收记录中。这些工作过去需要有人主动接着推进，现在有了明确负责的 Agent。

个人 AI 工具帮助开发者扩大自己能处理的范围。在这段实践中，我也观察到，原本分别负责 iOS、Android 的开发者，开始跨端推进完整功能。共享 Agent 则让调查线索、修复进展和测试反馈留在团队共同使用的记录里，供下一位接手的人继续工作。

这也是我理解的 Agent Native 实践：把 Agent 纳入日常分工，明确它持续负责什么、何时接到工作、结果交给谁。每个人仍然用 AI 处理自己的任务，也和共享 Agent 一起，把团队的问题从发现跟进到验证。

Holon 为这种分工提供了长期 Agent 和 WorkItem：角色可以长期存在，具体工作的目标、计划与后续事项可以保存下来。一次模型执行结束后，等待部署或人工反馈的工作仍然留着，条件满足后再继续。

故障调查和验收，是我们最先展开的两个案例。后续我还想写写代码审阅、产品分析，以及开发者怎样跨端推进一个完整功能。

如果你也想从团队共享的运行环境开始，可以参考远程访问与服务部署指南，了解如何让成员连接同一个 Holon 服务；再用 WorkItem 指南组织需要持续跟进的工作。先选一件团队里反复发生、交接边界清楚的事，比一开始就安排一整套 Agent 岗位更容易检验这种协作是否有用。

材料来源： 团队实践来自我的实际参与；数据和案例依据节点留存记录、GitHub Issue、评论与修复记录整理。