AI / 记忆
Agent Memory 选型指南: 五大范式、评测水分与四个必补动作
NOTE 同一个记忆框架, 在自家 benchmark 上可以报到 94.4 分 —— 而这个数字来自厂商托管平台的自测. 更麻烦的是: 同一类系统换一套测试脚手架, 分数能相差几十个百分点, 变量既不是模型也不是产品, 而是 谁写的评测代码 . 那么问题就不是"该买哪个", 而是: 在一个连分数都不可比的领域里, 选
TAG / A
AI Agent
aiagent·15 篇笔记·Agent 系统的设计、架构与工程实践, 不含模型原理本身
AI / 记忆
obsidian-second-brain 全解: 一个会自我重写的 AI 知识库
NOTE 你的笔记库在半年后会比今天更聪明吗? 大多数"第二大脑"的答案是不会 —— 它们只是一个更整齐的文件柜: 放进去的东西原样躺着, 三个月前的决策和昨天的决策互相矛盾, 而没有任何人知道. obsidian second brain 想换掉这个前提: 知识库不是往里面加东西, 而是围绕新信息重写自己 . 那么,
AI / Skill
Agent Skill 编写最佳实践: 上下文预算、触发工程与可证伪的验证
NOTE 为什么一个精心写好的 skill 会从来不被触发, 而一个写得普通的 skill 却总被误触发? 决定这件事的, 甚至不是它的正文. 更反直觉的是: 命名不合法、描述缺失、正文超预算 —— 这些失败 没有一个会报错 . skill 只是安静地从目录里消失, 而模型既看不到错误, 也分不清"不存在"与"写错了"
AI / Skill
SkillOpt: 把 skill 文档当参数来训练, 以及它在规范与可复现性上的边界
NOTE 如果一份 skill 文档写得不好, 为什么不能像调参一样把它"训"好? SKILL.md 是纯文本, 模型权重可以冻结, 任务分数就是现成的损失函数 —— 这条路听起来几乎无懈可击. 但真正的问题在另一头: 一个只会看任务分数的优化器, 知不知道 skill 该长成什么形状? 它怎么判断"变得更长"是进步还
AI / 检索
自建 Agent 检索栈: 本地化边界、凭证治理与可用性证明
NOTE 给 Agent 接检索, 最省事的做法永远是"买一个搜索 API 然后填 key". 可一旦把约束换成"尽量完全本地自建"和"凭证配置必须体面", 整个方案的形态就变了 —— 而且变的不只是选型. 更反直觉的是: 决定这套栈能不能长期活下来的, 往往不是检索算法, 而是 token 过期那一刻用户要面对多少摩
AI / Agent-Harness / DSH
DeepSeek Harness 提示词全解: 四个预设与每一步投递
NOTE 同一句"你好", 为什么在标准模式和极简模式里会被送出完全不同的请求头? 提示词在那台运行时里不是一段文字, 而是一组按 order 拼装、按预设挂载、按步骤重建的资产. 更反常识的是: 压缩指令不是另写的摘要 system prompt, 而是 追加在回放会话最后的一条 user 消息 —— 只为让这次旁路
AI / 记忆
自维护可插拔记忆层设计: 一次对比市面方案后的收敛
NOTE 一个 AI 在 A 项目里踩过的坑, 为什么到了 B 项目还要再踩一遍? 多数"记忆"系统只做到了同一工作区内的召回 —— 出了这个会话, 经验就归零. 真正想要的是另一件事: 让一次具体事故自动上升成一条对 所有 项目都成立的规则. 那么, 一个既能被任何 harness 读写、又能自己把经验拔高的记忆层,
AI / Agent-Harness / DSH
DeepSeek Harness设计思想: 插件树与事件日志
NOTE 一个 agent 最贵的时刻, 不是模型答错, 而是它在崩溃重启后 把已经改过的文件又改了一遍 . 要避免这件事, 光有"聊天记录"远远不够: 系统必须能回答三个问题 —— 这个能力是谁给的、这次副作用到底发生了没有、模型究竟看见过什么. DeepSeek Harness 把这些归属全部收进两根支柱: 插件树
AI / Agent-Harness / DSH
DSH Agent Loop 源码剖析
NOTE 用户说一句"用 echo 回显 ping", 会话里到底发生了什么? 没有聊天记录, 只有一条 turn/start step/start tool/call tool/result step/end 的事件串, 模型每次看到的历史都是现场推导出来的. 更反常识的是: 一次 step/start 到 step
AI / 记忆
AI Agent 对话记忆与知识库增量沉淀设计
NOTE 你的 Agent 记住的应该是什么? 是一堆日志, 还是一条 能从过去通向当下决策的链子 ? 如果一个用户今天改了偏好、明天打断纠正了你, 你的系统是"秒更新又能回答昨天", 还是两者顾此失彼? 日志该追加、知识该分视图、现状该覆盖、历史该双时态、错误该变成 skill —— 而这一切不始于某张精美的架构图,
AI / 基础
Agent要懂的LLM基础知识
NOTE 一个 Agent 聊到第二十轮突然不守规矩, 第一百零一次工具调用吐出坏 JSON —— 第一反应通常是"框架有 bug", 可如果问题根本不在框架里呢? 温度、分词、注意力这些看起来离业务很远的东西, 决定了 Agent 的成本、延迟与稳定边界; 把它们当成玄学调参, 就只会在同一个坑里反复摔. 0x00
AI / Agent架构
AI Agent设计原理与工程实践
NOTE 同一个模型, 换一套外壳, 有的 Agent 能可靠跑完一单退款, 有的却在第三步就编出一句"已经帮你处理好了"——差距究竟在模型里, 还是在模型之外? 上下文、工具、约束、验证、纠正, 每一环都决定它落地时是助手还是负担; 这篇文章要问的是, 把这些环节拼成生产可用的 Agent, 工程上到底要付出什么.
AI / Agent架构
Agent平台数据面灵活解耦
NOTE 如果所有 Agent 都跑在同一套基础设施上, 那么当某个业务要求更高隔离、另一套集群容量见底、某个客户坚持私有网络部署时, 平台还剩多少选择? "一个控制面管理多个数据面"听起来只是多了一层抽象, 可它决定的其实是平台能不能跨机器、跨集群、跨云落地. 0x00 背景 Agent 平台通常由控制面和数据面组成
AI / 多智能体
Multica agent协作与上下文机制
NOTE 在一个工作区里让一个 agent 去唤起另一个 agent 继续干活, 听起来只需要一句 @ ; 但它最容易长成的却是停不下来的成本循环 —— 谁该被叫醒, 被叫醒时它究竟带着哪些上下文? 更反直觉的是: 决定一次运行的并不是上一条评论, 而是 runtime 为这次触发临时注入的任务 brief. agen
AI / 多智能体
Multica智能体模板与小队编排skills调研
NOTE 用户说"这些技术栈都可以用", 一个 agent 会怎么理解? 大概率是把它们全部装进方案 —— 因为它把"可用"读成了"必用". 同一个问题在编排上还会再出现一次: 当"组一个小队"被理解成"把成员都 @ 一遍", 平台实际只唤醒了一个 leader, 其余人从未收到任务. 那么, 一套真正可交付的智能体编