“全天候智能体”在做什么？三份配置与一次公开运行

Hacker News 读者 CuriousRose 询问，人们所说的“全天候智能体”实际在做什么、模型能力如何、成本多少。他描述了自己的 SaaS 待办清单，以及难以理解有效产出如何形成、用户应在哪个环节介入的困惑。这是一条真实读者问题，并不证明那些被提及的部署有效，也不能证明某种架构占据主流。

已提供的原文给出一个范围有限的调查对象：github/gh-aw 的 Team Status 配置与 githubnext/agentics 的 Repo Status 配置要求生成仓库活动报告；githubnext/agentics 另一份 Cost Tracker 配置描述指定工作流完成后的成本报告。这些是具体配置的工作，不是所有智能体部署的代表性样本。

固定版本的 daily-team-status.md 声明每日定时与手动触发，并对仓库内容、议题和合并请求声明读取权限。它的 safe-outputs 块另行授权受约束的议题创建和旧报告处理。因此，一层中的读取权限不等于完整系统没有写入路径：发布报告本身就是通过受控输出机制完成的预期写入。

Team Status 的 bash 白名单列出 cat、ls、find、grep、head、tail、wc。输出配置规定标题前缀、固定标签、禁用提及、空的允许引用列表，以及关闭旧议题。这些是原文明确声明的边界，值得核查；配置文件本身却不能证明所有误用都会被拦截、内部模型调用存在某个上限，或生成的报告准确。

Repo Status 是另一仓库中的独立文件，材料没有证明它是 Team Status 的早期版本。两者的报告指令及部分权限、工具声明相似，但标题前缀与流程描述存在差别。Cost Tracker 则声明工作流完成事件触发、read-all 权限和包括 bash: true 在内的更宽工具范围。同属智能体工作流工具，并不意味着三者拥有相同能力。

已捕获的 Team Status 运行 #336 公开摘要显示：2026年10月18日11:30由定时器触发，状态为 Success，总时长4分45秒。页面列出的阶段为 activation 41秒、agent 2分19秒、detection 47秒、safe_outputs 15秒、conclusion 24秒。这些是页面展示的时长，不是 token 账单，也不能证明模型在整段运行中持续工作；不能将其相加后当作计费的 runner 用量。

页面列出八个工件，其中 agent 显示为446 KB、agent-output-fallback 为4.33 KB、usage 为73.4 KB。这些是工件名称和展示大小，不能据此确定模型生成文本的数量、证明回退曾触发，或判断模型与工具交互轮数。公开摘要要求登录后查看日志；本研究没有读取这些工件的内容。

已捕获摘要没有展示在本研究中独立评估过的报告正文或报告链接，这不等于报告本身私有或位于登录墙之后。成功标签说明所记录的工作流结论，不能证明报告事实准确、对团队有用、无需人工介入，或在多次每日运行中稳定可靠。

Anthropic 原文区分预定代码编排与由模型指挥自身流程和工具使用的系统。这可以作为分析视角，但仅凭产品名称、定时安排或一段编号指令，还不足以下确定分类。关键应是代码固定了哪些决策、模型实际做了哪些决策。

配置文件展示触发器、声明的能力、报告指令与获准输出，公开运行展示外层作业序列；两者都没有提供 agent 阶段的完整轨迹。固定的外层管线可以包含模型自行决定的内部循环；反过来，以智能体命名的工具也可能执行严格规定的工作。缺少内部轨迹时，断言模型从不选择工具，或所有阶段无论模型输出什么都必然运行，都超出了原文。

对读者更有用的是操作边界：什么启动一次运行、它能取得哪些上下文和工具、哪些输出可以进入仓库，以及人在哪一步核查有用性。定时执行与模型持续活动是两回事。这个例子让重复的维护工作变得具体，却没有确定内部自主程度、同类部署的普遍性或已经取得的价值。

Cost Tracker 原文描述读取 token-usage.jsonl、按模型汇总用量、套用内置费率表，再发布成本报告或告警。示例字段区分输入、输出、缓存读取和缓存创建 token；声明的计算规则将各类数量乘以相应的每百万 token 费率。这说明的是该实现的记账设计，内置费率未经验证为供应商当前价格，其计数口径也不能自动套到另一供应商的账单上。

已提供的追踪器配置把 agent-implement 与 agent-pr-fix 列为监控对象。这个文件既不能证明 Team Status 安装了该追踪器，也不能证明不存在其他成本报告。$1.00 高消费阈值是配置的告警设置，不是实测典型成本、花费上限，或本次运行不到一美元的证据。

已提供的公开材料没有确定运行 #336 的实际美元成本。完整比较需要相应模型用量记录及费率依据、适用的 runner 费用，以及重试和复核工作。页面总时长本身无法计算出这张账单。Cost Tracker 展示了收集证据的方法，但存在用量工件和换算公式，并不等于已经取得缺失的实测金额。

这些例子中的具体工作是仓库报告与成本报告，触发器和能力边界各不相同。公开 Team Status 运行提供可观察的执行结论与时长，配置文件提供预期行为。对读两者，比把“全天候”当作规格更有用：应分别看定时安排、一次运行中的获准操作，以及人能检查的实际产出。

采用类似工作前，应要求产出能够对应到配置和运行，检查准确性与有用性，并在可比的多次运行中收集完整用量和费用记录。这些是建议的验收步骤，不是本研究已经测出的结果。本研究不能排名前沿模型能力、确定典型成功率或投资回报，也不能回答团队需要修补多少夜间自主工作。一次成功摘要只是这种评估的起点。