---
title: "从个人 AI 工具到团队协作：一个小团队的 Agent Native 实践"
summary: "从开发者各自使用 AI，到共享 Agent 参与团队分工：用 77 天的留存用量、设备故障调查和琴键无声的实测案例，记录一个小团队的 Agent Native 实践。"
order: 40
---
# 从个人 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 混合协作，团队更多围绕目标组织工作，而不只按职能划分。[^frontier]
在这个小团队里，我使用一个更具体的定义：**Agent Native 组织是在安排职责、工作入口和交接方式时，就把 Agent 纳入团队，让它承担明确的工作角色。**
以故障调查为例。如果每次都要由开发者找到日志、粘贴到聊天窗口，再问“帮我分析一下”，AI 仍然主要是个人工具。把这项工作交给团队中的调查 Agent，就要进一步回答：新日志从哪里来？什么事件会通知它？它可以访问哪些材料？分析完写到哪里，又由谁接手？
具体到日常工作，需要安排好几件事：
- **有持续负责的事。** 调查 Agent 负责把现场整理成可调查的问题，测试 Agent 负责跟进修复后的验证；一次对话结束，不代表这段职责结束。
- **使用团队共有的工作记录。** Agent 从日志事件、GitHub Issue、代码变更和部署结果接到工作，把产出写回团队已有的记录，而不是只留在某个人的聊天窗口里。
- **能把工作交给人，也能接回反馈。** 需要真机操作时交给测试，需要产品判断时交给产品经理；人给出结果后，Agent 继续更新这项工作。
例如，测试 Agent 负责版本核对和接口检查，测试人员判断真实设备上的交互和体验，两者共同完成验收。
## Holon 在团队里承担哪些工作
服务器端的 Holon 是这些共享 Agent 的运行环境，不替代开发者本地的编码工具。它们参与的是产品研发，与产品提供给用户的 AI 功能不同。
团队目前使用的共享角色包括：
| 共享 Agent 的职责 | 接到什么工作 | 留给团队什么 |
| --- | --- | --- |
| trace 调查 | 日志上报、GitHub Issue | 现场分析、定位线索与待开发确认的问题 |
| 代码审阅 | PR、新提交与 CI 变化 | 审阅意见，以及修改后仍需跟进的事项 |
| 测试与验收 | Issue 关闭、测试环境部署完成 | 自动检查结果、人工复测要求与验收记录 |
| 产品运维 | 部署请求与巡检安排 | 可测试环境、部署记录与异常反馈 |
| 数据分析 | 分析需求 | 产品指标与会话统计，供团队讨论 |
| 团队协作助手 | 群消息与协调请求 | 整理后的需求、项目信息和交付材料 |
这六个角色的模型用量记录，可以追溯到 **2026 年 6 月 25 日**。统计到 **9 月 9 日**，共 77 天，留存记录中的累计用量约为 **77.64 亿 Token**：输入 76.94 亿，输出 0.70 亿。输入包含缓存读取和缓存写入，其中缓存读取约 62.59 亿，已经计入总量。[^activity]
*饼图展示六类角色在整个统计窗口内的累计用量占比。数值各自四舍五入，显示值相加可能与总量略有差异。*
这 77 天里，每天都有共享 Agent 的运行记录。模型用量主要集中在代码审阅、现场调查和测试验收上，其他角色则按需求参与。
在同一统计窗口内，我们还整理了产品主仓库里共享 Bot 留下的记录。按实际报告或审阅的发布时间筛选，再按 Issue、PR 去重，得到以下覆盖数：[^coverage]
| 工作记录 | 覆盖事项 | 如何计数 |
| --- | ---: | --- |
| 调查分析报告 | **858 个 Issue** | 识别明确的调查分析报告标题与证据内容标记，不计只宣布开始调查的评论 |
| 已提交的审阅 | **1,217 个 PR** | 有非空正文的正式审阅；同一 PR 多轮复审只计一次 |
| 验收与验证报告 | **652 个 Issue** | 识别明确的验收或验证报告，不要求结论为通过 |
验收记录包括代码检查、人工结果汇总和待复测结论。同一事项可以出现在多类记录中，表中数量不相加。
## 案例一：从设备现场到开发可以接手的 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，开发与测试可以直接查看。[^api-check]
### 琴键能不能发声，要到真机上确认
另一次问题发生在与 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](./why-work-items)：角色可以长期存在，具体工作的目标、计划与后续事项可以保存下来。一次模型执行结束后，等待部署或人工反馈的工作仍然留着，条件满足后再继续。
故障调查和验收，是我们最先展开的两个案例。后续我还想写写代码审阅、产品分析，以及开发者怎样跨端推进一个完整功能。
如果你也想从团队共享的运行环境开始，可以参考[远程访问与服务部署指南](/zh-CN/guides/connect-remote-runtime.md)，了解如何让成员连接同一个 Holon 服务；再用 [WorkItem 指南](/zh-CN/reference/work-items.md)组织需要持续跟进的工作。先选一件团队里反复发生、交接边界清楚的事，比一开始就安排一整套 Agent 岗位更容易检验这种协作是否有用。
---
[^frontier]: Microsoft WorkLab，*2025: The year the Frontier Firm is born*，2025 年 4 月 23 日。
[^activity]: 用量按六个共享 Agent 的留存记录去重汇总，窗口为北京时间 2026 年 6 月 25 日 00:00 至 9 月 10 日 00:00，不含个人编码工具及未留存记录。输入含缓存读取与写入；亿级数字和百分比保留两位小数。
[^coverage]: 覆盖数按产品主仓库共享 Bot 的调查、验收报告及正式 PR 审阅记录统计，在整个窗口内按 Issue、PR 去重。报告按标题和内容标记筛选；PR 检索范围为 2026 年 5 至 9 月创建的记录。
[^api-check]: 请求与响应的检查结果来自测试 Agent 保存的工作记录及 GitHub Issue 评论。
**材料来源：** 团队实践来自我的实际参与；数据和案例依据节点留存记录、GitHub Issue、评论与修复记录整理。
