“搜索改版这周能上吗？”
任务板写着开发完成，PR 已经合并，群里却还有一句“等接口补个字段”。你翻完一圈，才发现空结果页面还没验收。
让 AI 整理这些消息，它可以给出一份简报。但两个小时后，接口同事补了回复，测试又发现一个新问题。下一次有人问进展，它能接着这件事往下查吗？
这才是我想从 Agor 身上了解的部分。它把人和编码 Agent 放在同一个 Web 工作区里，关联分支、会话、看板与共享资料。周报是其中一个用法；值得展开的是，两份周报之间的事情怎么继续跟。
下面用一个虚构的搜索改版项目说明。人物、消息和输出都是设计示例，功能依据来自 Agor 官方文档。
第一次问进展，先把没确认的事找出来
假设周四上午，你手里有四条记录：
| 来源 | 内容 |
|---|---|
| 任务单 A | 页面开发完成，负责人小林；周三更新 |
| PR B | 周三合并，验证记录只有正常结果列表 |
| 讨论 C | 小林周三留言：空结果提示还需要接口返回一个字段 |
| 接口记录 D | 小周周三回复：字段预计周四补上 |
“页面开发完成”和“代码已合并”都有依据。空结果提示能不能用，还缺两件事：字段是否真的补了，页面是否验收过。
一份有用的进展简报，至少应该指出这些缺口。比如下面这份期望输出：
搜索改版｜周四上午
页面代码已合并，已有正常结果列表的验证记录（PR B）。
空结果提示依赖的字段，仍只有“预计周四补上”的说明，没有完成确认（讨论 C、记录 D）。对应页面也缺少验收记录。
下一步先找小周确认字段是否可用，再由小林补充空结果页面的验收结果。当前材料不足以确认上线条件。
这轮整理用普通聊天助手也能做。真正的问题在下一轮：小周回复之后，谁来把这份简报接上？
在 Agor 里，给这件事留一个固定位置
Agor 的 Teammate 是一个持续使用的助手角色。你可以在 Settings → Teammates → Create AI teammate 中建立“搜索项目简报员”，选择它的看板，再在它的分支中开启会话。
运行会话时仍要选择已配置好的执行工具。Teammate 保存的是这个助手的职责和持续工作的上下文，不会凭空获得 GitHub、群聊或任务系统的访问能力。
对这个项目，我会给它一份很小的工作说明：
你负责跟进搜索改版，给团队起草进展简报。
每次先读取指定的项目资料、上一份简报和未确认事项，
再检查这次提供的新记录。
逐项更新状态，保留结论的来源和最后确认时间。
有新证据确认解决的问题移出待确认列表，并记录解决依据；
有回复但仍未解决的继续保留，新问题单独列出。
来源不可访问就注明缺失。
生成草稿供负责人检查，不代替负责人承诺上线时间。
这段说明还需要填上实际资料入口。Agor 的 Knowledge 可以保存 Markdown 文档、历史版本和链接，供有权限的人及助手读取、修改。
先放几份文档就够了：项目范围和负责人、待确认事项、简报规则，以及每次简报。原始任务、PR 和讨论仍留在各自系统，文档里保存对应链接与最后确认时间。
其中，待确认事项是两次运行之间的接力点。上一轮留下的“字段是否可用”，下一轮要带着去找更新。
共享权限也要检查：放进 Knowledge，不等于每位同事默认都能读写。把项目参与者需要的访问权限配好，才能让他们查看并纠正这些记录。
小周回了消息，简报应该跟着变
继续这个例子。周四下午又来了两条虚构的新记录：
**记录 E，14:00，小周：**字段已部署到测试环境，附接口变更记录。
**记录 F，15:00，小林：**空结果提示已验证，但请求失败时也显示“没有找到结果”，需要修正后再验收。
现在如果简报还写“等待接口补字段”，它就已经过时了。如果写“接口已补，搜索改版完成”，又漏掉了新问题。
第二次跟进应逐项更新：
| 跟进事项 | 上午的情况 | 下午有了哪些变化 |
|---|---|---|
| 接口字段 | 等待小周确认 | 测试环境已可用，依据记录 E |
| 空结果提示 | 缺少验收记录 | 已验证，依据记录 F |
| 请求失败提示 | 原材料未覆盖 | 新发现与空结果提示混淆，依据记录 F |
| 上线条件 | 尚未确认 | 仍未确认，需要修正并重新验收 |
因此，第二份期望简报可以很短：
搜索改版｜周四下午更新
接口字段已在测试环境可用，空结果提示已有验证结果，上午的两项待确认已获得回复（记录 E、F）。
当前问题转为请求失败时的提示错误：需要小林修正，再补验收记录（记录 F）。测试环境的字段变更也不能直接作为生产环境已就绪的依据。
上线条件仍需确认，但继续追问的重点已经变了。
这里的变化不只是少写了几行字。同事能看见哪些问题已经有答复、现在该跟什么，以及结论为什么变化。下次接手的人，也有一条能沿着查回去的记录。
这些是希望助手完成的工作，并非 Agor 自动保证的结果。需要把读取旧记录、检查新来源、更新待确认项写进任务，并检查每次输出。
到周五，周报只是把这条记录收起来
有了连续跟进的材料，周报就有明确的内容可取：本周新增了哪些进展，之前的问题解决了什么，又留下了什么。
在这个例子里，周报应保留“页面代码合并”“测试环境字段可用”和“空结果提示已验证”的进展，同时留下请求失败提示的修正与复验。材料没写修正完成，就继续列为待办。
也要写清统计区间。旧消息今天被读到，不意味着它是今天发生的新进展。
手动检查几次能用后，可以设置 Branch Scheduler：从分支详情打开 Schedule，配置周期、执行工具和本次任务需要的上下文或 MCP 连接。它会按计划启动新会话，执行简报规则。
每次运行仍应显式读取项目记录和上期简报，不能假设新会话自带所有历史。读取外部任务、PR 或聊天记录，也需要配置对应连接。第一轮可以手动提供消息，先检查跟进逻辑是否靠谱。
调度以创建者身份运行，需要检查该身份的资料权限。文档当前注明调度使用 UTC；北京时间周五 17:00 对应 09:00 UTC，设置后再核对下一次运行时间。
什么时候值得多用这一层
如果只是偶尔整理几段文字，现有聊天助手已经能帮忙。Agor 更值得评估的场景，是同事需要围绕同一件事反复问进展、补材料、改结论，并共同查看这些变化。
判断它有没有帮上忙，可以从一个很小的问题开始：下一次有人问“搜索改版怎么样了”，团队是否还得从头翻一遍聊天记录？
这篇笔记受到 Maxime Beauchemin 的 《Raise a Team Helper Agent in an Afternoon》 启发，结合官方功能文档独立整理，未做部署测试。Agor 采用 BUSL-1.1，属于源码可用项目，详情见官方仓库。资料核对日期为 2026-11-08。
Agor 也收录在我们的 AI 团队工具清单：共享协作空间 中。想继续比较其他工具，可以看它们怎样共享会话、资料和交接结果。
