/always-on-agent-applications — 持久化 + 记忆实际解锁的能力
你正在帮助某人弄清楚可以用一个具有情景记忆的持续在线AI代理构建什么。这是一个关于'那又怎样？'的技能——架构已经存在，输入正在流动，现在它到底能做哪些无状态聊天机器人做不到的事情？
决策点
1. 持续在线 vs 会话式决策树
评估任务需求：
├─ 任务需要跨会话记忆？
│ └─ 否 → 使用会话式代理（更便宜、更简单）
│ └─ 是 ↓
├─ 任务受益于主动行为？
│ └─ 否 → 使用带记忆的定时代理
│ └─ 是 ↓
├─ [持久化投资回报率] > [基础设施成本]？
│ └─ 否 → 从会话式开始，后续升级
│ └─ 是 ↓
├─ 领域范围足够窄以保证记忆质量？
│ └─ 否 → 缩小范围（仅限会议、仅限代码）
│ └─ 是 → 构建持续在线代理
投资回报率计算：
- 持久化投资回报率 = (任务频率 × 每次任务节省的时间 × 用户每小时价值)
- 基础设施成本 = (服务器成本 + 存储成本 + 开发时间)
如果投资回报率 > 3倍成本：构建持续在线代理 如果投资回报率在1-3倍成本之间：从会话式开始，先证明价值 如果投资回报率 < 1倍成本：使用现有工具
2. 应用类别选择
用户问“我应该构建什么？”：
├─ 主要工作流是编码？
│ └─ 是 → 开发者伴侣模式
│ └─ 否 ↓
├─ 主要需求是会议/沟通开销？
│ └─ 是 → 个人幕僚长模式
│ └─ 否 ↓
├─ 主要目标是学习/知识工作？
│ └─ 是 → 学习日志模式
│ └─ 否 ↓
├─ 重点是健康/习惯追踪？
│ └─ 是 → 健康观察者模式（高安全敏感性）
│ └─ 否 → 项目编排器或环境智能
3. 范围边界决策
用户提出多领域代理：
├─ 这是他们的第一个持久化代理？
│ └─ 是 → 强制单一垂直领域（选择投资回报率最高的）
│ └─ 否 ↓
├─ 他们有超过6个月的开发时间？
│ └─ 否 → 仅限单一垂直领域
│ └─ 是 ↓
├─ 他们能为每个领域定义成功指标？
│ └─ 否 → 缩小范围直到能够定义
│ └─ 是 → 允许多领域但需分阶段发布
4. 主动行为校准
配置代理中断频率：
├─ 用户工作风格是深度专注块？
│ └─ 是 → 批量通知，尊重专注信号
│ └─ 否 ↓
├─ 用户明确要求高接触协助？
│ └─ 是 → 允许实时中断，但设置相关性阈值
│ └─ 否 ↓
├─ 默认为：80%被动响应，15%被动主动，5%主动主动
故障模式
1. 幻觉记忆综合征
症状：代理自信地引用从未发生过的对话或事件 检测规则：如果代理声称特定的引用/日期/事实但无法提供精确的源时间戳 根本原因：检索到的上下文与生成的响应之间记忆边界模糊 修复：实施严格的记忆引用要求——代理必须将每个声明链接到带有时间戳的特定记忆条目
2. 记忆污染级联
症状：代理性能随时间下降，响应中出现矛盾信息 检测规则：如果代理在7天内对同一主题给出矛盾的建议且未承认变化 根本原因：低质量观察积累速度超过有价值信号 修复：实施记忆卫生：相关性评分、自动压缩、用户触发的记忆清理
3. 成本失控爆炸
症状：月度账单增长30%以上但价值未按比例增加 检测规则：如果每次有用交互的成本在30天内比基线上升50%以上 根本原因：代理过度处理低价值输入（通知、垃圾邮件、自动邮件） 修复：输入过滤管道、记忆访问预算、带自动限流的主动成本监控
4. 范围蔓延麻痹
症状：代理试图处理一切，但一无所长，用户在两周后放弃 检测规则：如果代理拥有超过5个不同的应用垂直领域且每个领域没有明确的成功指标 根本原因：构建“通用助手”而非专注工具 修复：强制从单一垂直领域开始，要求通过毕业标准才能扩展
5. 隐私侵犯漂移
症状：代理意外地在不同上下文中共享敏感信息 检测规则：如果代理在错误上下文中提及个人/工作细节（工作信息出现在个人聊天中） 根本原因：记忆边界未与用户隐私期望对齐 修复：上下文隔离、显式记忆分区、定期隐私审计
实际示例
示例：构建开发者伴侣代理
场景：软件工程师希望代理帮助进行代码审查和PR描述
步骤1 - 范围定义
- 用户：“我想要一个能帮我更好地编码的AI”
- 应用决策树：编码工作流 = 开发者伴侣模式
- 缩小范围：“仅限PR描述生成”（不是完整的编码助手）
步骤2 - 投资回报率计算
- 任务频率：每天3个PR × 5天 = 每周15个PR
- 节省时间：每个PR描述5分钟 = 每周75分钟 = 每年65小时
- 用户价值：$150/小时 × 65小时 = $9,750/年
- 基础设施成本：约$50/月 = $600/年
- 投资回报率 = 16倍 → 构建持续在线代理
步骤3 - 记忆策略
- 核心记忆：当前功能分支、最近5次提交、最近关于代码变更的对话
- 回忆记忆：用户偏好的PR模板、审查者反馈模式、项目编码标准
- 归档记忆：历史PR、团队沟通风格、项目决策及理由
步骤4 - 触发器设计
triggers:
- git_push_to_feature_branch: 起草PR描述
- pr_opened: 用上下文增强描述
- code_review_received: 记录反馈模式以供将来使用
步骤5 - 质量门
- PR描述包含实际理由（而非通用摘要）
- 代理引用提到的具体提交/文件
- 80%的生成描述需要少于2分钟编辑
- 代理正确识别PR何时涉及多个关注点
新手会遗漏什么：从“全能AI编码助手”开始 专家会抓住什么：专注于单一高价值工作流（PR描述），其中持久化相对于无状态解决方案具有明显优势
质量门
应用设计完成时需满足所有条件：
- 清晰的投资回报率计算显示>3倍成本收益
- 单一垂直范围，带有定义的边界
- 记忆增长受限于压缩策略
- 主动行为频率已配置（少于总交互的20%）
- 成功指标已定义且可衡量
- 用户隐私边界已明确映射
- 冷启动体验可在没有累积记忆的情况下工作
- 已实现用户记忆控制的终止开关
- 已设置带自动限流阈值的成本监控
- 已为范围扩展定义毕业标准
非所属范围边界
不要将此技能用于：
- 构建记忆架构 → 使用
always-on-agent-architecture代替 - 设计输入源和触发器 → 使用
always-on-agent-inputs代替 - 安全性、隐私和成本问题 → 使用
always-on-agent-safety代替 - 通用代理模式和循环 → 使用
agentic-patterns代替 - 评估AI安全风险 → 使用
ai-safety-engineer代替 - 技术基础设施决策 → 使用
systems-architecture代替
当用户询问以下内容时，委托给其他技能：
- “如何存储情景记忆？” →
always-on-agent-architecture - “我的代理应该监控哪些数据？” →
always-on-agent-inputs - “这安全/隐私吗？” →
always-on-agent-safety - “如何构建代理循环？” →
agentic-patterns