129 posts tagged with "AI Agent"

长对话的 Agent Memory 不是「压缩就行」，是分层管理。

1. 问题核心：summary 平等压缩所有内容，用户核心目标和硬性偏好被一起稀释。
2. Working Memory：类似 system prompt 的常驻字段，永久不参与压缩，守住硬性约束。
3. 分段增量摘要：滚动窗口分段保存，每段打时间戳 + 优先级标签，不合并。
4. 向量数据库兜底：摘要丢细节没关系，原文存向量库按需召回。
5. 多 Agent 方案：Coordinator + Observer + Reflect + Retriever 四角色分工。
6. 场景选型：几十轮轻量对话 / 中长期 / 超长期多工具三档，对号入座。

AI 写 UI 最大问题是都长一个样。两个 skill 解。

1. 问题：默认审美"通用 slop"（AI 批量产的劣质模板）。
2. taste-skill：67.5k stars，"反 slop" 框架，风格库一键装。
3. Impeccable：49.9k stars，23 个命令 + 7 大模块知识库精细打磨。
4. 配合：风格约束 + 渐进打磨可叠加使用。
5. 安装：一行 npx skills add 即装即用。
6. 背景：都源自 Anthropic 官方 frontend-design skill。

多 Agent 协作系统设计有 8 个核心问题，一次讲透。

1. 角色拆分：决策 / 协调 / 执行三层，权限等级分开
2. 上下文传递：选择性注入 + 笔记本模式，避开上下文膨胀
3. 冲突仲裁：分类 + 证据链验证 + 置信度加权升级
4. 死循环破解：状态机 + 令牌桶 + 仲裁 agent
5. 共享记忆：共识 / 私有分层 + 命名空间隔离
6. 可观测性：监控 + 追踪 + 日志 + 全链路 trace
7. 效果评估：完成度 / 效率 / 经济性，必须 AB 对标
8. 错误恢复：澄清 → 规划校验 → 反思 → 仲裁兜底

多 Agent 不是 1+1>2，先看值不值再上。

RAG 和 Skill 不是替代关系，是解决不同问题的两套机制。混着用很容易踩坑。

1. 本质区别：RAG 按语义检索文档，Skill 按触发词加载流程
2. 必须用 RAG：3 类场景——开放域语料、答案分布广、用户不知道要看哪篇
3. Skill 能替代：3 类场景——知识结构化、触发条件明确、需要本地动作
4. 决策框架：是「检索」还是「执行」？前者 RAG，后者 Skill
5. Claude Code 案例：它用 Skill 不用 RAG，但 Skill 内部可以包 RAG
6. 混合方案：Skill 触发 + RAG 检索子语料，渐进式披露

核心结论：把 RAG 当 Skill 用、或者把 Skill 当 RAG 用，都是常见的设计错误。

三个原因：

1. 信息爆炸：AI 一次吐出的内容远超人能消化的密度，配图塞满模块，看完记不住结论。
2. 宏观对、微观不对：大方向常对得上，细节总差，要反复打磨 prompt。结合上条放大了消耗。
3. 承担更多：AI 让原本不归你干的事也变成了你干的事，加上行业卷效率，总量更大。

三个缓解动作：

1. 加密度上限：配图任务要求"一张图最多 3 个元素"，超出就拆。
2. 前置成功标准：每个 AI 任务先写一句"我需要什么具体结果"，再开工。
3. 明确责任边界：AI 干哪些、你干哪些，不因为 AI 能干就揽过来。

Agent 拿到视频链接只能读字幕，看不到按钮怎么点、报错在哪秒出现。

1. 核心问题：字幕里没有 UI、按钮点击时机、报错瞬间
2. 解决方案：yt-dlp 拉字幕 + FFmpeg 抽帧，按时间点对齐
3. 三档抽帧：快 50 帧 / 默认 100 帧（按镜头）/ 不限
4. 抽帧硬限制：2 fps，>10 分钟视频短促变化会被跳过
5. 时间戳定位：指定「2 分钟附近」重抽帧，画面更完整
6. 集成方式：ClaudeCode 走插件市场，其余装成 agent skill
7. 无字幕兜底：Groq / OpenAI Whisper（要 key）或本地 FunASR SenseVoice（免费离线）
8. 当前版本：0.2.0，仅读不写不剪

Agent 跑得慢，90% 的情况锅不在模型，在架构。架构选错，模型再强也是给一个漏水的桶灌水。

1. 性能瓶颈在哪：不是 token 慢，是 agent 闲着没事干还在转圈
2. 两种范式：Pull 模式（Loop 主动要任务）vs Push 模式（Event 主动叫 agent）
3. 传统 Loop 不是死循环：真正的 ReAct / Plan-Execute 是有终止的思考-行动-观察链
4. Event-driven 核心不是 push：是控制反转——agent 不用关心"什么时候该醒"
5. 适用边界：Loop 适合推理密集，Event-driven 适合 I/O 密集 + 异步多源
6. 反直觉：用错 Event-driven 反而更慢，因为它把"思考"也异步化了
7. 实战选择：高并发客服用 Event-driven，长链科研推理用 Loop

什么时候干什么活，比怎么干活更决定成本——这是架构选择的第一性原理。

记忆污染不是"清缓存重启"能收场的 bug，而是一次系统级的故障状态恢复。

1. 本质区别：缓存异常是死数据、抛错即停；记忆污染是 agent 带着错误记忆继续自主决策，且 自己不知道错了。
2. 攻击面：间接 prompt injection 把恶意指令藏进网页 / 文档，被 agent 写进长期记忆后静默持续执行。
3. 事前 三 道防线：索引与内容分离、容量约束 + 快照漂移防护、写入前准入扫描。
4. 事后三步走：全链路溯源 → 原子化回滚与补偿 → 认知重塑。
5. 两条红线：不设计无限记忆空间、不剥夺用户对记忆的回滚控制权。

海量 Skill 不能全量塞进 prompt，核心是渐进式披露（progressive disclosure）按需加载。

1. 为什么淘汰全量：token 是模型的注意力预算，工具目录涨到 200 个左右，工具选择准确率从 95% 断崖跌到 41%。
2. 三 层渐进式披露：L1 元数据索引 → L2 意图注入 schema → L3 触发 RAG 翻文档，token 开销砍掉 90% 以上。
3. 冷启动延迟：前端轻量路由分流 + 高频工具常驻 KV cache，响应时间缩短 30% 以上。
4. 状态断联：任务快照浓缩执行进度，切技能时注入，新技能原地复活。
5. 反过度设计：二三十个技能别上三层，前置语义过滤 + 精简 prompt 更稳。

面试官三轮的真实考察点，不是会调 API。

1. 一面（项目深挖，70 分钟）：从短期记忆到长期记忆、从成本控制到模型选型，全程追问项目细节，无八股文
2. 二面（系统设计）：从 0~1 搭一套商用 Agent 系统，边画架构图边追问落地细节
3. 三面（认知面/定级面）：聊赛道判断、个人差异化、1-2 年内行业瓶颈预测
4. 面试官要的不是会调框架的人：要的是做稳定、做可控、上线不出事的人
5. 新人别只写 demo：先把 token 机制、注意力机制这些底层搞清，再做有工程细节的完整项目