/always-on-agent-inputs — 为持久化智能体提供上下文
您正在设计一个始终在线智能体的所见、所闻和所知。架构技能处理记忆的存储位置。本技能处理记忆的内容——原始信号、结构化方式、智能体何时被唤醒，以及如何保持上下文窗口的诚实。
决策点
检索策略选择
Agent Task Type → Retrieval Strategy
IF conversational/chat:
├─ Use recency-first (70% temporal, 30% semantic)
├─ Budget: 15K conversation history + 4K recent recall
└─ Skip archival unless user asks "remember when..."
IF problem-solving/debugging:
├─ Use relevance-first (60% semantic, 40% temporal)
├─ Budget: 8K archival + 4K recall + 2K ambient
└─ Include error patterns from past solutions
IF context-switch detected:
├─ Use frequency-based (what does user work on most?)
├─ Budget: 6K project context + 2K recent + 4K goals
└─ Pull entity history for active files/people
IF scheduled trigger (morning briefing):
├─ Use structured agenda (calendar + tasks + updates)
├─ Budget: 4K calendar + 4K unfinished tasks + 2K changes
└─ No conversation history needed
IF reactive trigger (CI failure, meeting starting):
├─ Use event-specific context loading
├─ Budget: 8K event context + 4K related history
└─ Skip general conversation unless relevant
环境数据过滤
Screen/Audio Observation → Filter Decision
IF same app + same text for >5 minutes:
└─ DISCARD (no change, noise)
IF app switch detected:
├─ KEEP transition record
└─ Score relevance of new app content
IF high-signal keywords found:
├─ Check against active projects/goals
├─ IF match score >0.6 → STORE to archival + recall
├─ IF match score 0.3-0.6 → STORE to recall only
└─ IF match score <0.3 → DISCARD
IF technical error/exception visible:
├─ ALWAYS STORE (debugging context)
└─ Tag with urgency level
IF calendar event mentioned:
├─ ALWAYS STORE (temporal anchor)
└─ Cross-reference with actual calendar
触发器紧急度分配
Event Type + Context → Urgency Level
IF CI failure:
├─ Production branch → ACTIVE (notify user)
├─ Feature branch + user currently coding → PASSIVE (mention when user next engages)
└─ Old branch/PR → SILENT (log only)
IF meeting starting:
├─ <5 minutes → ACTIVE (interrupt with prep)
├─ 5-15 minutes → BADGE (show prep available)
└─ >15 minutes → SILENT (prep in background)
IF code change detected:
├─ First commit on new branch → PASSIVE (note new work)
├─ Commit fixes previous error → PASSIVE (note resolution)
└─ Regular commits → SILENT (track progress)
IF mentioned in Slack:
├─ Direct message → ACTIVE (respond needed)
├─ Channel mention + urgent keywords → ACTIVE
└─ Channel mention, normal → BADGE (review when convenient)
失败模式
模式膨胀
- 症状： 上下文窗口持续达到上限，响应缓慢，尽管有过滤但 Token 成本高
- 根本原因： 观察模式捕获了每个字段，而不是仅捕获智能体推理所需的字段
- 检测规则： 如果平均上下文大小 >50K Token 或观察存储 >1MB/天，则存在模式膨胀
- 修复： 每月审计模式。删除过去30天内未影响决策的字段。使用摘要而非原始存储。
检索抖动
- 症状： 智能体引用过时信息，遗漏近期上下文，或重复检索不相关的记忆
- 根本原因： 单次向量检索未重排序，或时间/语义权重调整不当
- 检测规则： 如果 >30% 的检索上下文在响应中未被使用，或用户纠正智能体关于近期事件的信息
- 修复： 实施两阶段检索（广泛搜索 + 重排序）。A/B 测试不同的时间/语义权重比率。
触发器噪音
- 症状： 用户禁用智能体通知，抱怨被打断，或智能体被忽略
- 根本原因： 无紧急度分级，或主动/打断触发器的阈值设置过低
- 检测规则： 如果用户关闭 >50% 的主动通知，或用户平均参与间隔 >4 小时
- 修复： 默认所有设置为静默。让用户明确配置什么值得主动通知。跟踪关闭率。
上下文陈旧
- 症状： 智能体基于过时信息行动，错过用户变更焦点/项目
- 根本原因： 上下文无时效衰减，或检索权重未充分考虑近期性
- 检测规则： 如果智能体引用超过7天的信息而近期上下文存在，或提及已完成的项目
- 修复： 对相关性评分添加指数衰减。将近期观察的权重设为档案的 2-3 倍。
环境噪音泛滥
- 症状： 成本高，响应质量差，智能体提及无关的屏幕内容
- 根本原因： 原始环境数据绕过过滤，或相关性门控设置过于宽松
- 检测规则： 如果环境观察占存储记忆的 >30%，或 Token 成本 >$10/天
- 修复： 收紧相关性评分。将环境观察批量处理为5分钟窗口。需要2个以上信号确认相关性。
工作示例
场景：受限 Token 预算下的账单 Bug 调查
用户报告：“企业客户的账单计算有误。”
第1步：上下文预算分配（总计40K）
System + Identity: 4K tokens (fixed)
Core Memory: 2K tokens (user preferences, active projects)
DECISION: Problem-solving task → use relevance-first retrieval
Allocated: 8K archival + 4K recall + 2K ambient + 15K conversation + 5K output buffer
第2步：检索策略执行
# Broad semantic search for billing-related memories
archival_candidates = vector_search(
query="billing calculation enterprise customer error bug",
top_k=20,
filters={"project": ["billing", "payments"]}
)
# Rerank by true relevance (not just embedding similarity)
reranked = rerank_results(archival_candidates, query, top_k=5)
# Result: Gets "enterprise discount logic bug from 3 weeks ago"
# that pure vector search ranked #12
# Temporal search for recent billing work
recent_work = temporal_search(
time_range="last_7_days",
entity_filters=["billing", "enterprise"],
max_results=3
)
# Result: User was debugging pricing tiers yesterday
第3步：环境上下文集成
# Check what user is currently doing
screen_summary = get_ambient_summary(last_30_minutes)
# Result: "User has billing_calculator.py open, looking at
# calculate_enterprise_discount() function"
# Budget check: 8K archival + 4K recent + 2K ambient = 14K (under budget)
第4步：快速与完整权衡 智能体有两个选择：
- 快速检索（当前）： 14K 上下文，聚焦近期 Bug 模式
- 完整上下文： 添加 Git 历史、相关 PR 讨论（+8K Token，超出预算）
决定： 初始响应采用快速检索。如果用户要求深入调查，则触发后续扩展上下文预算。
智能体响应质量：
- 新手方法： 将所有账单相关上下文倾倒出来，超出预算，得到混乱的响应
- 专家方法： 精选14K最相关上下文，提到了纯向量检索会遗漏的3周前的企业折扣 Bug，并保持在预算内
质量门禁
- 上下文窗口分配在各层级（系统/核心/检索/对话）之间明确预算
- 每次请求的平均 Token 总数在日常交互中 <40K
- 环境观察在存储前经过相关性流水线过滤
- 检索使用两阶段过程（广泛搜索 + 重排序）
- 所有触发器按紧急度分类（静默/徽章/被动/主动/打断）
- 观察模式包含时间戳、置信度分数和来源
- 过滤流水线已测试：响应中未使用的检索上下文 <30%
- 用户关闭的主动通知 <20%（触发器噪音检查）
- 智能体在可用时引用近期信息（最近24小时）而非默认使用档案
- 存储增长率 <100MB/周/用户（效率检查）
不适用边界
使用 /always-on-agent-inputs 来处理：
- 决定从用户环境中捕获哪些数据
- 结构化触发器和观察模式
- 上下文窗口预算和检索策略选择
- 在数据到达智能体之前过滤环境数据
不要用于：
- 记忆架构设计（向量存储、数据库、记忆层级）→ 使用
/always-on-agent-architecture - 应用和用例构思 → 使用
/always-on-agent-applications - 捕获数据的隐私和安全 → 使用
/always-on-agent-safety - 通用提示工程技术 → 使用
/prompt-engineer - 智能体推理模式 → 使用
/agentic-patterns