跳到主要内容

TAG / S

Skill

skill·4 篇笔记·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 / 多智能体

Multica智能体模板与小队编排skills调研

NOTE 用户说"这些技术栈都可以用", 一个 agent 会怎么理解? 大概率是把它们全部装进方案 —— 因为它把"可用"读成了"必用". 同一个问题在编排上还会再出现一次: 当"组一个小队"被理解成"把成员都 @ 一遍", 平台实际只唤醒了一个 leader, 其余人从未收到任务. 那么, 一套真正可交付的智能体编

相关标签与本标签共现最多