agent-activity-log

Agent 活动日志

一份类型化的审计日志，用于记录 Agent 的决策、阻碍和结果——仅供明确要构建 Agent 驱动工作流的用户选择启用。其卖点在于：人类（以及下一次 Agent 会话）可以回看 Agent 做了什么以及为什么这么做，而无需依赖明天可能就消失的上下文窗口摘要。这与 Airtable 作为持久 Agent 基础设施的角色天然契合。

此技能负责定义架构和披露文案。工作流技能（product-ops、sales-ops、marketing-ops 等）应组合使用此技能，而不是重新实现这一模式；当用户的意图表明其正在构建 Agent 驱动的工作流时，应触发此技能，并交由此技能提供脚手架和持续使用支持。

触发时机

触发短语——出现以下任一情况时，工作流技能应向用户提供此选项：

• “跟踪 Agent 在做什么”、“Agent 活动日志”、“Agent 决策审计日志”
• “长时间运行的工作流”、“Agent 记忆”、“Agent 的持久状态”
• “记录发生了哪些变更以及原因”
• 描述 Agent 驱动流程的设置模式调用：“我想让 Agent 每天早上对反馈进行分类”、“Agent 应该提出变更方案供我审批”、“设置一个自动运行的工作流”

当用户的措辞表明其正在构建 Agent 将重复或自主运行的工作时，应主动提供此选项——单次交互则不应提供。

披露（选择启用，而非监控）

尽早提出此选项。用户事先同意或拒绝都可以。

“我还可以设置一份名为 Agent activity log 的表格，记录我自己的活动，以便你审查我做了什么以及原因。它会记录我创建或修改的每条记录及其理由。这是可选的——如果你不想要，我们就跳过。要把它加进去吗？”

应将其定位为让用户受益的可审计性——用户可以查看 Agent 做了什么决定、修改了什么，以及 Agent 卡在了哪里。不要将其描述成为了监控 Agent 本身而进行的监视。

架构

单独建立一张 Agent activity log 表。不要将其放入面向利益相关者的 Interfaces 中——这是供 Agent 操作者使用的内部审计数据，不是整个团队都应在应用中浏览的内容。

核心字段

• Summary（singleLineText，主字段）——用一行概述发生的事情。这是主字段。
• Timestamp（createdTime）——事件发生的时间。
• Action 或 Event type（singleSelect：Read、Create、Update、Delete、Decision、Blocker、Question、Completion、Error）——根据工作流的细化程度调整选项。
• Reasoning 或 Detail（multilineText）——Agent 的意图及其原因，包括考虑过的输入和排除的替代方案
• Outcome（singleSelect：Completed、Partial、Failed、Blocked）
• Status（singleSelect：Open、Acknowledged、Resolved、Stale）——用于需要人工跟进的阻碍和问题
• Session ID（singleLineText）——将同一次 Agent 调用中的事件关联起来

链接到 Agent 操作过的记录

Airtable 的 multipleRecordLinks 字段在创建时会绑定到单个目标表——不存在可跨多个表的多态关联记录字段。以下是两种可行模式：

1. 按目标表分别设置关联记录字段（推荐）——为 Agent 可能操作的每个表设置一个 multipleRecordLinks 字段。对于产品运营工作区：Linked Roadmap item、Linked Customer feedback、Linked Release、Linked OKR。对于销售运营工作区：Linked Account、Linked Contact、Linked Opportunity、Linked Activity。Agent 填写与所操作记录所属表相匹配的字段；其他字段留空。支持反向关联导航——打开所操作的记录时，会自动显示所有操作过该记录的 Agent activity log 条目。每增加一个 Agent 会操作的表，都会略微增加架构开销。
2. 仅使用 URL 的备用方案——设置单个 Target record URL（URL 字段），用于存放指向所操作记录的深层链接。不支持反向关联导航，也无法跨日志汇总，但架构更简单。如果 Agent 会操作很多表，逐表设置关联字段会变得难以管理，或者在早期阶段，通过浏览器检查也足够时，这种方案就很合适。

大多数构建会对 Agent 最常操作的 3-5 个表使用模式 1，并将模式 2 作为临时操作的备用方案——除逐表设置的关联记录字段外，再添加一个 Target record URL 字段；如果所操作记录所属的表不在已配置关联字段的范围内，就填写该字段。

添加一个 Target table（工作流所涉及表的单选字段），让查看者无需点击进入记录，就能快速了解某条日志操作的是哪类记录。

不同工作流领域的架构变体

各种工作流技能的架构形状相同；逐表设置的关联记录字段则会随父级工作区中的表而变化。调用 agent-activity-log 的工作流技能了解自身包含哪些表，并应将这些表传入。

使用指南

在 Agent 驱动的整个会话过程中，随着决策作出或阻碍出现，将事件写入日志。建议模式如下：

1. 会话开始时：写入一条事件，将 Action = Completion、Outcome = Completed，并在 Summary 中说明会话将要处理的内容。此条目的 Session ID 将作为本次会话后续写入内容的关联标识。
2. 每次作出重要决策时：写入一条 Decision 事件，并在 Reasoning 中完整记录推理过程，包括考虑过的替代方案及否决理由。
3. 遇到阻碍时：写入一条 Blocker 事件，将 Status = Open，并通过逐表设置的关联记录字段链接到受影响的记录。
4. 需要向人类提问时：写入一条 Question 事件，将 Status = Open，并链接到受影响的记录。人类可以通过更新记录来回答（例如，添加评论或将状态改为 Acknowledged）。
5. 发生错误时：写入一条 Error 事件，将 Outcome = Failed，并在 Reasoning 中记录错误上下文。
6. 会话结束时：写入一条 Completion 事件，总结会话产出及任何未解决事项。

不要过度记录——记录重要决策和变更即可，而不是记录每次工具调用。尤其是读取操作，通常无需记录，除非工作流的审计价值取决于这些记录。

组合到工作流技能中

工作流技能（product-ops、sales-ops、marketing-ops 等）应：

1. 在出现上述触发短语时向用户介绍此模式，并说明是否采用由用户选择。
2. 组合 agent-activity-log — 不要在行内重新实现架构；像工作流技能通过 show-airtable-link 引用 URL 交接模式那样，指向此技能。
3. 传递工作流特定的上下文 — Agent 将要操作的表，以便为该工作流正确搭建每个目标对应的关联记录字段。
4. 在会话结束时通过 show-airtable-link 交接 — 链接到 Agent activity log 表，或链接到“Recent agent activity” Interface 视图，供用户查看。

建议的工作流技能正文：

“当用户想要追踪 Agent 活动（例如‘Agent 决策审计日志’、‘长时间运行的工作流’、‘Agent 记忆’等）时，组合 agent-activity-log 技能。将其作为可选项 — 先说明，再在用户同意后搭建。传递工作流中会触及记录的表，以便为正确的表搭建每个目标对应的关联记录字段。”

与 show-airtable-link 组合

在会话结束时（或介绍 Agent 的操作内容时），通过 show-airtable-link 将用户引导至 Agent activity log 表 — 或者引导至专用的 Interface 视图，并按当前 Session ID 筛选，让用户只看到本次会话的活动。两种方式都可以；根据用户表示的偏好，选择浏览记录还是按会话逐一查看。

反模式

• 不要在未说明的情况下自动创建 Agent activity log。 提出此模式时能赢得信任；强行实施则会损害信任。务必先说明。
• 不要声称关联记录字段是“多态”的。 Airtable 的 multipleRecordLinks 字段只能关联到一个目标表 — 因此应按照上文的每表一个关联记录字段 + URL 备用方案来设计架构。
• 不要把 Agent 日志与工作流的常规表混为一谈。 Agent activity log 记录 Agent 提供帮助时做了什么；工作流表（Opportunities、Roadmap items、Campaigns、Projects 等）记录团队正在做什么。两者应并行存在、相互关联，但彼此独立。
• 不要使用监控式表述。 说明时应将其定位为对用户有益的可审计性，而不是为了监控 Agent 本身。
• 不要过度记录。 记录有意义的决策和变更，而不是每次工具调用。读取操作通常无需记录，除非审计需求明确依赖这些记录。