Mobility的 RSS 预览

从实现逻辑出发，搭一个能干活的 Agent

2026-09-24 12:00:00

<h1 id="从实现逻辑出发，搭一个能干活的-Agent"><a href="#从实现逻辑出发，搭一个能干活的-Agent" class="headerlink" title="从实现逻辑出发，搭一个能干活的 Agent"></a>从实现逻辑出发，搭一个能干活的 Agent</h1><blockquote>背景：这篇是读《深入理解 AI Agent：设计原理与工程实践》（李博杰，Apache 2.0 开源，GitHub: bojieli/ai-agent-book）的整理笔记。全书十章，从原理讲到工程实战，配 88 个可跑的实验。下面不按章节复述，而是按”实现一个 Agent 要解决哪些问题”重排，每个模块只讲两件事：要解决什么问题，核心思路是什么。细节和数据留给原书。</blockquote><hr><h2 id="一、Agent-的本质：一个公式和一个循环"><a href="#一、Agent-的本质：一个公式和一个循环" class="headerlink" title="一、Agent 的本质：一个公式和一个循环"></a>一、Agent 的本质：一个公式和一个循环</h2>问题：Agent 到底由什么构成，最小可运行形态长什么样？思路：<code>Agent = LLM + 上下文 + 工具</code>。直觉说法是”大脑 + 眼睛 + 手脚”，学术说法是策略 + 观察空间 + 动作空间。最小实现只有一个 while 循环：把消息列表发给模型，返回工具调用就执行并把结果追加进去，没有工具调用就输出退出。这个循环叫 ReAct（思考 → 行动 → 观察）。支撑它的三条性质必须理解到位：<ul><li>每次调用无状态，模型要的一切必须完整出现在消息列表里；</li><li>模型只决策，执行在框架侧——模型说调什么、传什么参，真正跑代码的是你的代码；</li><li>上下文 = 静态前缀 + 轨迹，前缀是系统提示词加工具定义，轨迹是随交互增长的消息历史。后面所有的优化都建立在这个切分上。</li></ul>消融实验给出了各组件的必要性：缺工具定义彻底不能动，缺工具结果会反复调同一个工具直到卡死，缺思考过程前后决策矛盾，缺历史消息等于失忆。工具不必多。七个就够了：代码解释器、Bash、读/写/编辑文件、Glob、Grep。这不是简化，而是主流通用 Agent 的真实配置——开放任务型 Agent 的内核就是一个 Coding Agent 加一个文件系统，因为代码是唯一能”创造新能力”的元能力。<hr><h2 id="二、Harness：模型之外的竞争力"><a href="#二、Harness：模型之外的竞争力" class="headerlink" title="二、Harness：模型之外的竞争力"></a>二、Harness：模型之外的竞争力</h2>问题：同样的模型，为什么有的 Agent 稳定可靠，有的一跑就崩？思路：把公式扩展成 <code>Agent = Model + Harness</code>。Harness 是围绕模型搭的全部支撑代码，除上下文和工具外，还包括约束（能做什么、不能做什么）、验证（结果对不对）、纠正（错了怎么补救）。一句话区分：上下文和工具让 Agent 能做事，约束、验证、纠正让 Agent 不做错事。生产级系统里，绝大部分代码属于后者——权限分类、上下文压缩、熔断器、错误恢复。范式是层层包含的：软件工程 ⊂ 提示工程 ⊂ 上下文工程 ⊂ Harness 工程 ⊂ Loop 工程（跨轮次的持续自主运转）。当各家模型能力趋近，竞争优势就转移到这一层。关于模型和 Harness 的消长，务实的立场是：模型还做不稳的，Harness 先补上；模型每内化一层，Harness 就卸下一层，去兜底新的能力前沿。<hr><h2 id="三、上下文工程：能力上限的真正决定因素"><a href="#三、上下文工程：能力上限的真正决定因素" class="headerlink" title="三、上下文工程：能力上限的真正决定因素"></a>三、上下文工程：能力上限的真正决定因素</h2>问题：模型够聪明，为什么在具体业务上还是不好用？思路：模型智力是基础，上下文质量才是上限。一个中等模型配上组织好的上下文，常常胜过顶级模型在信息匮乏下摸索。KV Cache 是硬约束，不是优化项。 前缀里有一个字符变化，整条缓存作废。所以三条铁律：系统提示词和工具定义定稿后不改；所有动态信息（时间、状态、计数）追加到末尾；永远用标准 API 消息格式（自己拼文本会偏离训练格式，削弱多步思考能力）。有团队在系统提示词里塞了一行当前时间，首 token 延迟从 0.5 秒涨到 3–5 秒，账单几乎翻倍。提示词写 SOP 而不是规则堆砌。 内容不变、只打乱组织结构，任务成功率能掉 30% 以上。业务规则要细到可执行，模糊规则会让同一个任务在不同时间得到不同分类。提示词太长就按需加载，这就是 Skills。 三层渐进式披露：元数据常驻（几百 token）→ 核心流程按需加载 → 细则引用子文档。关键是 <code>description</code> 写成路由条件（Use when / Don’t use when 加反例），”何时该用我”比”我能做什么”重要得多。把隐式状态显式化，这就是 Agent 状态栏。 上下文窗口是一台只有一半的检索引擎：检索极强，但没有”提炼层”。所以模型数不清自己打过几次电话——解法是在工具结果里直接写”本次是第 3 次”。状态栏用一条追加在末尾的消息承载任务进度、环境状态、工具计数。两条经验：用代码维护而不是让模型去总结（模型批量统计长历史反而不如 20 行正则）；光给读数不够，必须连”读数该怎么用”的策略一起给。膨胀了就压缩，但更该隔离。 压缩不只是省长度，更是把需要思考才能得到的结论变成可直接检索的知识；生产上是分层的（大输出落盘、噪声直接删、归档式摘要、最后才是全量压缩），且必须显式定义保留优先级——最容易丢的是早期架构决策和失败路径。更釜底抽薪的是隔离：让子 Agent 去翻十几个文件，只回传一句结论，几万 token 根本不进主上下文。<hr><h2 id="四、记忆与知识库"><a href="#四、记忆与知识库" class="headerlink" title="四、记忆与知识库"></a>四、记忆与知识库</h2>问题：会话结束后，怎么让 Agent 记住用户、接上外部知识？思路：两个尺度——用户记忆（个体）和知识库（群体），共用底层技术（检索、压缩），面临同样的麻烦（冲突、过期、检索不准）。记忆设计有三套正交分类：存在哪里（轨迹 / 长期记忆 / 业务状态）、怎么存（从极简的 Simple Notes 到带来源背景和关系的 Advanced JSON Cards）、存什么（情景 / 语义 / 程序记忆）。取舍在简单性与表达力之间，成熟系统混合使用。再往外一步是”用户即代码”：把记忆变成带类型的可执行对象，能做聚合统计、冲突发现、约束执行这三件文本记忆做不了的事。检索是稠密 + 稀疏 + 重排序三件套。 稠密懂语义但会漏精确关键词，稀疏精确但读不懂同义表达，两路融合后再用跨编码器精排。索引前给每个文本块加”出自哪里”的前缀（上下文感知检索），检索失败率能降近一半。扁平检索不够时要结构化：RAPTOR 建知识树适合由宏观到微观，GraphRAG 建实体关系图擅长多跳推理和消歧。代价不小，只在确实需要跨文档综合时才值得。最终形态是双层：少量关键事实结构化后常驻上下文提供全局概览，海量原始对话按需检索取细节。只常驻会丢细节，只检索发现不了跨会话关联——主动服务这类能力只有两层叠加才落地得了。<hr><h2 id="五、工具：Agent-的手与眼"><a href="#五、工具：Agent-的手与眼" class="headerlink" title="五、工具：Agent 的手与眼"></a>五、工具：Agent 的手与眼</h2>问题：怎么让模型准确、安全地使用外部能力？思路：五类工具——感知、执行、协作、事件触发（Agent 注册、外部触发）、用户沟通。描述比能力重要。 大多数调用失败的根因不是模型不知道工具能做什么，而是不知道它不能做什么。所以：写”何时用”而非”能做什么”，参数给具体例子而非规范名，说清返回值结构和执行代价，附 1–5 个真实示例。工具超过 100 个，再强的模型也容易选错。Agent 选错工具时先查描述，别急着换模型。参数传递必须透明。 不能在模型不知情的情况下改输入或输出，否则会制造一个模型永远诊断不了的系统性故障（比如静默把中文引号转成英文引号，导致匹配永远失败）。MCP 解决互操作，代价是工具定义会吃掉大量上下文（几个服务器就可能有几万 token），所以要默认只给索引、按需查定义，工具多了还要做动态发现。执行侧的安全是多层防线。 输入验证快速失败、绝不”智能修正”；权限控制不能只有黑名单（<code>rm -rf /</code> 能靠变量展开绕过），要做命令的语义解析；危险操作用两种独立视角把关——提议者-审核者审开放式思考（两个能力相近但不同家族的模型），Sidecar 只审结构化调用数据（轻量模型够用，且刻意不读主模型的自由文本，以免被话术操纵）。沙盒要认清 venv 不是沙盒，真正的隔离是 OS 级、容器到 microVM 三级，且默认断网——掐断外传通道比识别每一次注入确定得多。异步是真实部署的常态，但模型训练假设同步。 折中办法是让模型在常态下看到完美同步的轨迹，只在被真打断时才插入占位符修补格式，并且只在紧急时才打断。事件按紧急度分三种处理：取消式、队列式、并行式。一句总结：真正的主动服务不仅需要 Agent 定时检查世界，更需要世界能主动通知 Agent。<hr><h2 id="六、以-Coding-Agent-为骨架搭起来"><a href="#六、以-Coding-Agent-为骨架搭起来" class="headerlink" title="六、以 Coding Agent 为骨架搭起来"></a>六、以 Coding Agent 为骨架搭起来</h2>问题：一个能处理开放任务的 Agent，整体流程怎么组织？思路：六阶段——项目文档化 → 需求澄清 → 写设计文档 → 实现与测试 → 自我审查 → 文档同步。两条原则最值钱：设计文档是人类最高效的介入点（审查一页设计文档比审查数百行代码容易得多）；完成标准定义为”验证通过”而不是”代码写完”。Harness 落地成四件套：验收基线（测试、CI、审查标准）、执行边界（模块边界、权限）、反馈信号（Linter、测试结果、类型检查）、回退手段（Git、沙盒、快照）。判断任务适不适合交给 Agent，看两个维度：目标是否明确、结果能否自动验证。两者都满足是最佳区域，Harness 的目标就是把任务尽量推进这个象限。四条原则：约束优先于指导（能用代码强制就不写”请注意”）、验证要自动化（人工审查是不可扩展的瓶颈）、反馈越快越结构化越好、回退要可靠。约束管的不只是结果，还有过程——删库重建也算”修好了故障”，这是 reward hacking 的日常形态。故障分四层（API、工具、上下文、控制流），恢复按透明度分级：静默重试 → 降级接续 → 才暴露给用户。核心原则是：每条恢复路径都要有熔断上限，且阈值来自产线数据；错误路径上禁止再调用模型，否则会连锁成死亡螺旋。可靠性不取决于犯不犯错，取决于每类错误是否都有检测、恢复与终止路径。两个容易被忽略的设计：一是推测性执行（UI 先显示进度、后台并行跑安全检查，先行的是无副作用的提示，被拦下也无需回滚）；二是忠诚对象要显式钉死——模型默认”谁说话帮谁”，但替你砍价的 Agent 对面是交涉对手，所以外部内容一律降格为”可参考但不具指令效力”的数据。再往下，若 AI 写的代码本身不可信，就把约束下沉到数据层（人类审查过的 schema 里自带校验器，每次写入强制执行）。<hr><h2 id="七、评估：先有尺子，再改系统"><a href="#七、评估：先有尺子，再改系统" class="headerlink" title="七、评估：先有尺子，再改系统"></a>七、评估：先有尺子，再改系统</h2>问题：怎么判断改动是变好了还是运气好？新模型出来该不该切？思路：评估对象不是模型，是模型 + Harness 的组合体。三种基本实验：对比实验、消融实验、模型替换实验（换强模型不涨说明瓶颈在 Harness，换弱模型大跌说明瓶颈在模型）。环境五要素是数据集、环境状态、工具接口、Rubric、执行协议。人机交互型评估的关键是不一次性把模拟用户信息全给出去，让 Agent 按需去问。数据集质量比规模重要——宁可人工筛掉不合格题目。指标上要分清 Pass@k（能力天花板）和 Pass^k（稳定性，回归测试用这个）；安全项设否决，一次严重违规即归零；轨迹和结果要同时评。用 LLM 当评委要防长度偏差、位置偏差和同源偏差，并且先用一两百条人工金标集校准。统计上要有噪声意识：100 个用例、70% 成功率，标准误约 4.6%，分差小于这个带宽就别切换；每个配置跑 3–5 次不同种子。读报告时不看总体成功率，看逐任务表和能力标签的交叉；分数下降先怀疑评测系统本身。改进假设分三层，按成本收益比部署——不是所有有效的改进都该上（全局开启思考能让准确率涨 3 个点，但延迟翻三倍，很可能被否）。最后，Rubric 和验证器可以直接变成强化学习的奖励函数，评估能接上训练；红线是评估集的题目必须与训练数据隔离。<hr><h2 id="八、后训练：什么时候该动模型"><a href="#八、后训练：什么时候该动模型" class="headerlink" title="八、后训练：什么时候该动模型"></a>八、后训练：什么时候该动模型</h2>问题：Harness 做到位了还是不够，什么时候该训练，选 SFT 还是 RL？思路：三阶段代价差数量级——预训练学世界知识（最贵）、SFT 用示范对学格式与风格（最便宜）、RL 用任务加奖励学可迁移策略（常是 SFT 的几十倍）。一句话概括：SFT 记忆，RL 泛化。SFT 倾向记住训练里的答案，环境一变就失效；RL 学的是策略，面对没见过的情况更稳。对比实验里，分布外场景下 RL 通常涨几个到几十个点，SFT 反而下降。顺序是先形后神：SFT 先把格式立住（连 JSON 都产不稳时 RL 会完全失败），但不宜恋战，过拟合的损伤 RL 救不回来。转向 RL 的临界点是——再加示范数据也没用，因为瓶颈在 SFT 的优化目标本身。优先级是基础模型 > 环境 > 算法。仿真环境够不够真实、示范和奖励信号质量够不够高，比选 PPO 还是 GRPO 重要得多。两个高频坑：不要用后训练记事实（那是 RAG 的活）；工具调用训练必须做 loss masking，屏蔽环境返回的 token，否则模型会去学”预测沙盒会输出什么”。<hr><h2 id="九、自我进化：不改权重也能长大"><a href="#九、自我进化：不改权重也能长大" class="headerlink" title="九、自我进化：不改权重也能长大"></a>九、自我进化：不改权重也能长大</h2>问题：部署之后怎么让 Agent 越用越好，而不是每次重来？思路：自我进化即外部化学习——把知识和流程从参数和临时上下文里分离出来，变成可持久化、可检索、可复用的资产。前提是承认学习不会自动发生：注意力更像检索而非推理，所以学习必须被显式设计。产物形态按性质选：纯事实 → 知识库条目；常用且参数复杂 → 专用代码工具；常变且涉及策略判断 → Skill 文档。四条路径：从成功里学（把成功轨迹浓缩成策略摘要，入库判据是可迁移性）、从重复任务里学（工作流录制，但必须编译成带验证谓词的状态机，且入库前重置环境回放验证一遍，否则程序库会越攒越坏）、从失败里学（反思入库、建错误模式库和负面规则）、睡眠学习（离线整合记忆，检测矛盾、合并、剪枝）。工具侧的进化是：先能按需发现工具（不必全量塞进上下文），再能自己创造工具。安全边界要一并设计——供应链攻击、能力漂移、工具质量退化，以及比会话内注入更隐蔽的记忆投毒（跨会话持续生效）。<hr><h2 id="十、能力边界的扩展"><a href="#十、能力边界的扩展" class="headerlink" title="十、能力边界的扩展"></a>十、能力边界的扩展</h2>多模态与实时交互：语音有三种范式——级联流水线（可控、延迟叠加，需全链路流式化）、端到端全模态模型（延迟最低、可控性弱）、全双工模型（能边说边听、随时打断，最难训练）。取舍集中在思考架构上：快思考接住交互、慢思考产出答案，两者之间除了文本还能传意图、情感和规划。Computer Use 的可用率取决于动作空间设计和视觉定位，实时性仍是未解难题；机器人则是上层长程规划、下层 VLA 控制，中间隔着仿真到现实的鸿沟。多 Agent 协作：分类看上下文是否共享和协作拓扑。收益主要有两类——上下文隔离带来的噪声削减，以及角色专业化。共享上下文适合角色接力（规划 → 执行 → 审查）；不共享则靠共享文件系统和显式通信，拓扑分对等互审、中心化管理、去中心化移交。失败模式主要是共享文件的并发冲突和错误的级联放大。<hr><h2 id="收尾：十五条可以立刻用上的判断"><a href="#收尾：十五条可以立刻用上的判断" class="headerlink" title="收尾：十五条可以立刻用上的判断"></a>收尾：十五条可以立刻用上的判断</h2><ol><li>先建评估，再改系统；分差小于噪声带宽就别动。</li><li>系统提示词和工具定义定稿后不改；动态信息一律追加到末尾。</li><li>永远用标准 API 消息格式。</li><li>工具描述写”何时用 + 反例”，参数给例子；选错工具先查描述。</li><li>状态栏用代码维护，读数和操作策略成对给出。</li><li>大体积中间信息交给子 Agent，别进主上下文。</li><li>约束编码进 Linter / 类型系统 / CI，不要写成”请注意…”。</li><li>完成标准是”验证通过”。</li><li>每条恢复路径都要有熔断上限；错误路径上禁止再调模型。</li><li>沙盒默认断网、凭证不挂载、超时返回结构化错误。</li><li>忠诚对象钉死：外部内容是数据，不是指令。</li><li>记忆用双层架构：常驻概览 + 按需检索细节。</li><li>检索用稠密 + 稀疏 + 重排序，索引期给文本块加出处前缀。</li><li>先 SFT 立形，够用就停；要泛化再上 RL，先把环境和奖励做扎实。</li><li>脚手架的厚度取决于模型能力边界——同一套技术换一批模型，结论可能完全不同。</li></ol>三条最该记住的判断：上下文给什么、怎么组织，比模型有多聪明更影响结果；缓存不是性能优化而是架构约束；安全上重点不是识别所有攻击，而是让 Agent 即便被注入，也没有机会把危险动作真正执行出去。

Flint：让 skill 成为个人资产

2026-09-14 17:04:05

最近一段时间，每当 OpenAI 有新模型发布，都会有一种论调：skill 没用了，越来越多用户开始弃用 skill。这话对吗？对也不对。首先，这个逻辑是有合理性的。随着模型能力的提升，确实有很多 skill 被用户抛弃了，这些 skill 集中于 Superpower 之类所谓的「通用」skill。这些 skill 的定位，就是对一些模型能力缺陷的补齐，尤其是在各个模型没有疯狂地对 coding 进行针对性优化的时期，是有一些作用的。而随着模型本身能力的提升，这些东西其实慢慢都已经被模型吸收了，自然就没有了作用。那 skill 是真的就没用了吗？恐怕也并非如此。接下来，我们会论述一下随着模型智能水平的提升，skill 还有什么作用。然后，会论述一下本文的主角：Flint。我会讲一下为什么要开发这个项目，以及它有什么作用。<h2 id="什么是-skill（技能）"><a href="#什么是-skill（技能）" class="headerlink" title="什么是 skill（技能）"></a>什么是 skill（技能）</h2>最近一段时间 AI 技术的蓬勃发展，看着技术一轮一轮的迭代，但实质上只是软件工程理论的再一次落地。其中，skill 这一层，目标是实现「可复用性」，对应的是软件开发中的各种工具包。而模型对应的是软件开发语言这一层。复用程度的不同决定了一个功能是应该在语言层还是在工具包里。比如，数组或者 map，就应该在语言里封装好，而不是你得引个第三方包才能用。而比如一个解析发票的逻辑，那么落到语言层里，就不合适了。对应到 AI 当前的发展，skill 的定位就应该是这样的功能：有一定复用性，但复用性又不高、AI 没有足够的语料自主学会这个。比如，公司内封装的工具包的使用方式，尤其是一些可能已经被淘汰掉的古早技术栈，模型拿不到足够的语料获取相关知识，相关知识只存在于相关开发人员的脑子里，这时候，就适合封装一批 skill 出来，成为团队固化的知识；比如，你自己将自己的工作流固化出来的一些流程，比如我会用 Notion 管理工作任务，然后基于这个生成周报，那就可以封装成一个 skill 给 AI 使用；再比如，我包了一个访问我带着真实 cookie 浏览器的 skill，在访问一些反爬比较强的网站时，就可以用这个 skill。就像这种 skill，包一个很简单，但如果想从网上下一个，却没那么容易。现在有些 agent 自己也会封装这样的能力，但用起来或多或少总会有一些不合心意。所以，随着模型能力的提升，skill 并不会消失，但其起效果的范围会收敛到这些复用性不高不低的事上。不复用会很麻烦，但又不会有很普世的复用性。你下载下来别人的 skill，会发现不好用。这也是我开发 Flint 这个项目的初衷，就是：把 skill 像个人资产一样管理。<h2 id="Flint-是什么"><a href="#Flint-是什么" class="headerlink" title="Flint 是什么"></a>Flint 是什么</h2>Flint 是我开发的一个本地优先的个人 AI Skills 资产管理器（官网：<a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a>）。一句话概括：把你散落在各个 Agent、各个项目里的 skill 集中管起来——统一打标签、搜索筛选、同名去重，再按需投放到每个 Agent 和项目自己的技能目录里。它由一个本地后端和一个 Web 前端组成，一条脚本就能启动；你的技能仓库对应磁盘上一个普通目录，各 Agent 的技能目录通过软链或复制从这个源头分发。从此技能只有一份本体，放在你自己的地盘上，用到哪投到哪。界面上 Flint 分成六个模块，各管一件事：<ul><li>技能库：浏览、搜索、过滤你所有的 skill，预览 <code>SKILL.md</code> 原文、编辑标签、追溯每个技能的来源；也可以在这里登记自有仓库和第三方只读仓库，把散在各 Agent 里的技能归集回仓库，或从任意目录批量导入。</li><li>智能体：每个实际的技能目录一张卡片。在这里把某个 Agent 设为活跃、关联预设、逐个开关技能，甚至按单个技能切换软链还是复制。</li><li>预设：一组 skill 套餐——显式成员加上关联标签命中的技能。预设没有开关，成员或标签一变，立刻分发到关联了它的活跃 Agent。</li><li>项目：登记项目路径和标签，匹配的 skill 自动进入项目的 <code>.agents/skills</code> 目录（可以提交进 git，跨机器自包含）；项目里改出来的技能还能回写仓库。</li><li>诊断：六个维度的体检——同步、重复、失效软链、配置、仓库、项目，问题集中列出来，确认后一键修复。</li><li>设置：默认安装方式（软链 / 复制）、复制模式的增量同步 watcher、自定义 Agent、日志查看。</li></ul>前四个模块串起来就是「收拢 → 整理 → 投放」的主路径，诊断和设置是兜底：出了状况去诊断页看问题出在哪，投放的默认姿势在设置里定。下面两张界面截图可以建立点直观印象（均为演示数据）。技能库页：所有技能集中在一处，卡片上直接看描述和标签，顶栏按来源、标签筛选：<img src="/img/flint-library.jpg" alt="技能库：集中浏览、搜索、按来源和标签筛选">诊断页：六个维度的体检结果一屏列清。截图里「重复技能」的两条警告，正是同一个技能在自有仓库和第三方来源各存了一份，等着被收编成一份：<img src="/img/flint-health.jpg" alt="诊断页：六维体检，重复来源集中列出"><h2 id="为什么需要它"><a href="#为什么需要它" class="headerlink" title="为什么需要它"></a>为什么需要它</h2>除了上文说过的部分，还有一个现实因素，让我更需要对 skill 进行精细化的管理。就是我需要经常性地切换不同的 agent。现在赛博菩萨很多，今天 WorkBuddy 放个免费模型，明天 TraeWork 发一批免费积分，千问、小米，这些也都不甘落后。这些免费的 token，不用白不用。但在经常切换 agent 的情况下，skill 的管理就成问题了。今天我可能在 WorkBuddy 里实现了写日报的 skill，明天打开 TraeWork，发现用不了。现在固然有 npx 等各种工具管理 skill，但我试了一下，都不太趁手。现在市面上的绝大多数 skill 管理工具，核心思路还是基于分享与分发，目标是建设一个大而全的 skill 仓库，然后安装到用户自己的各个 agent 里。这样会带来几个非常显著的问题。<ol><li>就是我们前边说的复用性问题。别人的 skill，下载下来通常运转得不会特别好，相信大家对于这一点或多或少都应该有些感受。而另一方面，让我们回到文章一开头，如果一个 skill 真的复用性非常好，开箱即用，那它大概率会被吸收进模型本身，反而没有必要作为一个 skill 存在。</li><li>切换 agent 的成本问题。npx 能一次性把 skill 安装到各个现存的 agent 里，但一旦使用新 agent，这个操作就很麻烦了。另一个重大问题是自己的 skill，无法纳入到 npx 等工具的管理中，会给切换 agent 带来巨大负担。</li><li>skill 使用的成本问题。比如一个公司内的 skill 集，可能有一两百个 skill，里边前端、后端、设计、运营各种 skill 都有，你可能只能用到其中一小部分，但如果没有精细化的管理手段，就只能把所有 skill 都安装进来了。这样，几乎所有主流 agent 都会把每个已安装技能的名称和描述注入系统提示词，供模型自行判断要不要调用。按每条描述 50～100 token 估算，200 个 skill 就是每次对话 1 万～2 万 token 的固定开销，再乘上 agent 一次任务的几十个来回，账单相当可观。而且开销还在其次，更麻烦的是检索效率：候选列表越长、无关条目越多，模型选错技能或干脆漏选的概率就越高，就像在塞满了别人工具的工具箱里找自己那把扳手。</li></ol>基于上述原因，我开发了 Flint 这个项目。为什么用这个名字，灵感来自于 Obsidian。Obsidian 在官网上用三句话概括过自己的理念：Sharpen your thinking（磨砺你的思考）、Your thoughts are yours（你的想法属于你自己——笔记私密地存在你的设备上，别人读不到，连官方也读不到）、Your knowledge should last（你的知识应当长存——使用开放文件格式，你永远不被锁死，长期拥有自己的数据）。Flint 沿用了同一套「以石喻工具」的命名脉络：黑曜石（Obsidian）是天然锋利的火山玻璃，远古人类把它打制成刀刃；燧石（Flint）是与黑曜石并肩的另一块「工具之石」，只是把打磨的对象从「知识」换成了「技能」。燧石的两层特性，正好对应这个项目的两个动作——打制（knapping）：把散落的 skill 收拢、去重、打标签，敲成精确趁手的工具；取火（spark）：把技能投放、分发到各个 Agent 与项目目录，让它们真正被点燃、开始干活。你收藏的每一项技能，都是等待被击出火花的一块燧石。<h2 id="核心理念：像-Obsidian-管理知识一样管理技能"><a href="#核心理念：像-Obsidian-管理知识一样管理技能" class="headerlink" title="核心理念：像 Obsidian 管理知识一样管理技能"></a>核心理念：像 Obsidian 管理知识一样管理技能</h2>正是沿着和 Obsidian 一脉相承的思路，Flint 把那三条理念逐条搬到了技能管理上：<table><thead><tr><th>Obsidian 的理念</th><th>Flint 的对应</th></tr></thead><tbody><tr><td>本地即私有</td><td>技能只以普通文件存在你的本地磁盘，无云端、无账号、无上报</td></tr><tr><td>开放格式、永不锁定</td><td>skill 本体就是磁盘上的 <code>SKILL.md</code> 目录，随时可打开、编辑、diff、用 git 提交；换工具、换生态，这份资产照常带走、照常使用，不被 Flint 绑定</td></tr><tr><td>磨砺你的思考</td><td>收拢、去重、打标签，再一键投放到需要它的 Agent 与项目里，让个人技能库越攒越趁手</td></tr></tbody></table>落到具体设计上，还有两个值得一提的取向。其一，元数据尽量贴合开源生态共识：标签优先写在每个 <code>SKILL.md</code> frontmatter 的顶层 <code>tags</code> 字段上——这个位置能被 Claude Code、agentskills.io 等 40+ 工具原生读取，并随技能目录一起被 git 版本化，而不是存进某个私有数据库。其二，尽量降低生态碎片化：同名技能多来源时自动去重、只保留一份，重复、分歧、失效引用都集中到诊断页看清并就地处理，避免同一份 skill 在你的环境里以多个副本反复膨胀。<h2 id="最小通路：四条步骤跑通"><a href="#最小通路：四条步骤跑通" class="headerlink" title="最小通路：四条步骤跑通"></a>最小通路：四条步骤跑通</h2>Flint 是个跑在本机的小工具（Node.js ≥ 20），官网 <a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a> 上有介绍和截图，用法文档写得比较全，这里只把第一次使用的四条必要步骤捋一遍：<ol><li>安装：仓库根目录执行 <code>./start.sh</code>，脚本会自动检查 Node 版本、依赖与端口占用，首次运行自动 <code>npm install</code>，装完打开浏览器即可（前端 <code>localhost:5173</code>，后端 API <code>localhost:8787</code>）。</li><li>登记仓库：仓库是 skill 的集合与事实源，对应磁盘上一个目录。自有仓库正常维护；第三方仓库作为只读来源登记，里面的技能随时可以被自有仓库「导入」收用。</li><li>新建预设：一个预设就是一份 skill 套餐——显式成员并上关联标签命中的技能。</li><li>把预设应用到 Agent：在某个 Agent 的详情页先把它「设为活跃」，再关联刚建的预设。此后预设的成员或关联标签一变，已关联它的活跃 Agent 会立刻拿到这套 skill。</li></ol>至此，「登记仓库 → 配预设 → 投给 Agent」的最小通路就打通了，你的技能已经可以跨 Agent 工作。再往后的归集、接管、项目专属技能、六维诊断，都是锦上添花。预设详情页长这样（演示数据）：上半部分是当前状态——这个预设最终会开启哪些技能、已经应用到了哪些 Agent；下半部分是两种调整方式，「按标签纳入」和「按技能纳入」取并集，改动立即生效：<img src="/img/flint-preset.jpg" alt="预设详情：显式成员与按标签纳入取并集，改动即刻分发"><h2 id="小结"><a href="#小结" class="headerlink" title="小结"></a>小结</h2>以上就是我对于未来 skill 变化趋势的理解，和开发 Flint 的缘由。如果大家认可这个思路，欢迎来试用产品并提出建议。项目已经开源，官网在 <a href="https://flint.lichuanyang.top/">flint.lichuanyang.top</a>，代码仓库在 <a href="https://github.com/lcy362/flint">GitHub: lcy362/flint</a>，clone 下来执行 <code>./start.sh</code> 就能跑起来体验；<code>README.md</code> 里有完整的使用指引，欢迎试用后提 issue 交流。如有帮助，还请帮忙点个star。

从薅 token 到管 skill：我的 pks 工具落地实践

2026-07-01 17:16:24

之前写过一篇文章：<a href="https://lichuanyang.top/posts/26060/">https://lichuanyang.top/posts/26060/</a> . 教大家构建与Agent无关的工作流，随时能拉起不同的Agent工作，从而能顺畅用上各个Agent提供的免费、试用套餐。这么实践下来，一个明显会变得繁琐的事情就是对于skill的管理。因此，我又写了一个工具，实现在不同Agent、不同项目间管理skills.鉴于目前Agent的生态还比较凌乱，大家各干各的，skill的存放目录也自己定自己的。比如 Cursor 放在 <code>~/.cursor/skills</code>，Claude Code 放在 <code>~/.claude/skills</code>，Trae 放在 <code>~/.trae/skills</code>，OpenCode 放在 <code>~/.config/opencode/skills</code>，还有 Windsurf、Qoder、Hermes 等等，每家都有自己的路径约定。社区也在试图定义通用的.agents/skill这样目录，有点作用，但不大。当然，skill管理的问题，也不全是使用多Agent带来的。因为skill这种东西，天然就就有非常大的适用范围区别。有的skill是适用于公司的项目的，有的是适用于自己的项目的，有的适用范围还更窄一点，只适用于若干范围内的几个项目，还有的skill, 比如汇总新闻的，我想只配在某个agent里。你要是问，不对skill做这些精细化的管理，行不行？那确实也没什么大问题，无非就是agent每次检索技能，多花点token. 但做技术的强迫症，还是希望把这些东西管的细一些，在不需要agent调起的地方，就压根别让agent能看到这些skill.基于此，设计了pks这个工具。核心思路是在一个集中的地方管理所有的skill, 然后，按照需求，将skill写入agent的skill目录或者项目目录下。具体来说，支持以下功能全局管理：所有 skill 集中存放在 <code>~/.local/share/pks/skills/</code> 下，用 <code>pks list</code> 查看，用 <code>pks new</code> 创建新 skill。项目级安装：在项目目录下执行 <code>pks init</code> 初始化后，可以用 <code>pks install</code> 把全局 skill 安装到当前项目的 <code>.skills/</code> 目录。Agent 级安装：用 <code>pks install-to <agent> <skill></code> 把 skill 直接装到指定 agent 的 skill 目录（比如 <code>~/.cursor/skills/</code>）。双向同步：在项目里改了 skill 文件，用 <code>pks push</code> 把改动推回全局库。实际使用上，我大概有这么些使用场景：有一些skill是小范围适用的，比如相关的几个有限的工程，这时候，我不会将skill放到agent的配置里，而是会放到项目中，使用pks install命令，可以把本地技能库中的skill, 放到工程目录下。然后可以在AGENTS.md文件中指引agent去skill目录下找技能，对于支持项目内技能的agent, 也可以使用pks link命令，将agent对应的项目内技能目录，比如.opencode/skills, 软链到skills目录下；有些skill, 比如收集新闻的skill, 我只想让它在部分agent中出现，这样就执行pks install-to命令, 将其装到agent的skill目录下。有时候skill文件需要修改，我会先在某个项目下进行修改，然后执行pks push, 将命令写回技能库。这样，对于skill, 就有了一个比较妥善合理的处理流程。项目地址在： <a href="https://github.com/lcy362/personal-skills-manager">https://github.com/lcy362/personal-skills-manager</a> ，欢迎试用。大家有什么其他关于skill管理的经验，也欢迎提出。

把笔记、微信读书、知乎装进 Obsidian：我基于llm-wiki知识中枢搭建实录

2026-06-26 16:18:13

前段时间，偶然看到karpathy大神提出的llm-wiki, 有种相见恨晚的感觉。我一直是很喜欢写些东西的，但是写完之后，问题就是大量内容散落在各个地方，一直没有精力对它们进行有效的管理。而看到了llm-wiki后，我就意识到，之前写的那些东西，要开始发挥作用了。<h2 id="为什么需要知识中枢"><a href="#为什么需要知识中枢" class="headerlink" title="为什么需要知识中枢"></a>为什么需要知识中枢</h2>首先, llm-wiki是什么。llm-wiki 是 Andrej Karpathy 在最近提出的一个概念：把你过往积累的所有文字材料——笔记、博客、读书摘录、工作日志——作为”语料库”，让 LLM 自动从中提取概念、建立页面、编织交叉引用，最终形成一个结构化的、可持续迭代的个人 Wiki。它的核心前提很简单：每个人在日常工作和学习中已经产生了大量有结构、有见解的文字，只是它们散落在各处，缺乏关联。llm-wiki 要做的就是用一个 LLM 驱动的流程，把这些散落的珍珠串起来。你负责持续产生和收集内容，LLM 负责组织和管理。和传统的手动 Wiki 维护不同——建页面、写摘要、加链接，枯燥且难以坚持——llm-wiki 把组织成本降到了几乎为零。你只需要告诉 LLM 你的知识库结构和维护规则（即一个 AGENTS.md 文件），它就能反复执行摄入、更新、审计等操作。我自己实践下来的感受是，看着 AI 把零散笔记变成结构化的交叉引用网络，有一种”债务清零”的快感。<h2 id="数据接入"><a href="#数据接入" class="headerlink" title="数据接入"></a>数据接入</h2>我做的第一件事，就是把之前在notion里写的各种笔记，有开发知识、投资知识，还有各种各样零碎的记录，都导出然后放到了obsidian里。如何将 Notion 内容导入 Obsidian？实际操作并不复杂，核心步骤如下：<ol><li>导出 Notion 数据：在 Notion 的”设置与成员 → 设置”中，选择”导出所有工作区内容”，格式选 Markdown & CSV。导出后会得到一个 ZIP 包，解压后每个 Notion 页面对应一个 <code>.md</code> 文件，数据库则额外附带 CSV。注意：Notion 免费版每次只能导出一个工作区，如果你有多个工作区，需要分别操作。</li><li>安装 Obsidian Importer 插件：在 Obsidian 社区插件市场搜索”Importer”并安装。这个插件支持从 Notion、Bear、Evernote、OneNote 等多种工具一键导入，会自动处理图片附件和内部链接。启用插件后，用 <code>Cmd+P</code> 打开命令面板，搜索”Importer: Open Importer”，选择 Notion 格式，选中刚才解压的文件夹即可。</li><li>手动导入（备选方案）：如果不使用 Importer 插件，直接将解压后的文件夹放入 Obsidian vault 目录即可。Obsidian 原生支持 <code>[[wiki-link]]</code> 格式的内部链接，Notion 导出的 Markdown 中的链接通常已经转换为该格式。</li><li>后续处理：导入后建议将原始文件放入一个专门的子目录（比如 <code>raw/notion-export/</code>），标记为”不可修改”。这样保留了原始数据的完整性——这是 llm-wiki 方法论中很重要的一环：原始素材永不可改，LLM 在此基础上生成结构化知识。如果你的 Notion 中有数据库，CSV 文件可以作为参考保留；如果某些页面嵌入了 Notion 特有的 Block（如日历、看板），导出后这些会丢失交互性，但文本内容会保留。</li></ol>整个流程走下来，我几千条分散的笔记就这样汇入了 Obsidian，成为了知识中枢的第一批”原料”。然后将karpathy那篇gist喂给AI, 生成出项目的AGENTS.md文档，AI能够自然的写出llm-wiki所需的摄入、审计等操作。接着就可以执行了。看着AI不停的生成wiki内容，把我之前的积累分类整理，还是非常舒适的。再往后，我又做了几件事，就是把知乎的创作和微信读书的笔记也纳入进来。知乎上我写了上千篇回答，微信读书几年读了上百本书，除了笔记之外，这些也是我知识体系的重要组成部分。正好，差不多那段时间，微信读书发布了官方的skill, 我也就顺手用了起来。<h2 id="知乎收藏导入"><a href="#知乎收藏导入" class="headerlink" title="知乎收藏导入"></a>知乎收藏导入</h2>如何将知乎创作同步到 Obsidian？知乎没有提供官方的数据导出 API，这里我用 Playwright 做了浏览器自动化。操作步骤：<ol><li>安装 Playwright：<code>pip install playwright && playwright install chromium</code></li><li>首次运行脚本，在打开的 Chromium 浏览器中扫码或密码登录知乎</li><li>登录成功后脚本自动遍历个人主页，抓取所有回答、文章和想法</li><li>登录状态持久化保存到本地，后续通过 <code>--reuse</code> 参数静默执行，无需再次登录</li></ol>特点：增量同步，每次只抓取新内容，已有文件不重复处理；按回答/文章/想法分类存放。<h2 id="微信读书笔记同步"><a href="#微信读书笔记同步" class="headerlink" title="微信读书笔记同步"></a>微信读书笔记同步</h2>如何将微信读书笔记同步到 Obsidian？微信读书开放了 Agent API Gateway，申请 API Key 后即可调用。操作步骤：<ol><li>调用 <code>/user/notebooks</code> 接口获取有笔记的书籍列表</li><li>对每本新书，分别拉取划线和想法内容</li><li>按章节分组，输出为规范的 Markdown 文件</li></ol>输出格式：书名和作者作为标题，每章划线以引用块形式列出（附带日期），笔记和想法附在对应原文下方。特点：完全增量同步，脚本维护已同步书籍 ID 的状态文件，每次运行只处理新增的书籍。151 本书的笔记就这样悄无声息地流入了 Obsidian，成为了知识中枢最丰富的一批原料。<h2 id="LLM-Wiki-智能检索"><a href="#LLM-Wiki-智能检索" class="headerlink" title="LLM Wiki 智能检索"></a>LLM Wiki 智能检索</h2>到此，内容层的准备基本就完成了。然后我又想，既然我大部分的知识和创作都在这儿了，是不是可以开始蒸馏我这个人了？这块先搞了一版简单的，就是把拆分出一个和wiki类似的personal流程，也有ingest、lint等流程，区别就是wiki的重点是知识，而personal的重点是我这个人。知识库 vs 人格蒸馏：两种不同的 AI 处理逻辑这里有必要解释一下两者的区别——它们共享同一套原始素材，但目标和产出完全不同。知识库（Wiki）：回答”我知道什么”从笔记、博客和读书摘录中提取客观知识，生成概念页面（如”分布式一致性”）、实体页面（如”Raft 算法”）、来源摘要页面（如”《数据密集型应用设计》读书笔记”），并在它们之间建立密集的交叉引用。目标是让知识变得可查询、可复用，像一个外部化的第二大脑。人格蒸馏（Personal Model）：回答”我是谁”从创作和阅读中反向推导认知模式、表达风格和价值取向。例如，通过分析技术博客，可以归纳出”论点先行、案例驱动”的表达风格；通过分析知乎回答，可以发现”第一性原理还原”和”量化思维”等反复出现的认知特征。产出不是知识条目，而是一个人的认知图谱——擅长什么、怎么思考、看重什么。两者的异同<table><thead><tr><th>维度</th><th>知识库</th><th>人格蒸馏</th></tr></thead><tbody><tr><td>核心问题</td><td>我知道什么</td><td>我是谁</td></tr><tr><td>输入</td><td>笔记、博客、读书摘录</td><td>一切个人创作和阅读记录</td></tr><tr><td>产出</td><td>概念/实体/来源页面 + 交叉引用</td><td>领域深度/认知特征/表达风格/价值观</td></tr><tr><td>方向</td><td>向外看：结构化外部知识</td><td>向内看：建模个人认知</td></tr><tr><td>流程</td><td>摄入 → 查询 → Lint → 审计</td><td>摄入 → 查询 → Lint → 审计（同构）</td></tr></tbody></table>两者在流程上高度相似，但一个是向外看，结构化和整理你拥有的知识；一个是向内看，蒸馏和建模你作为个体的认知特征。这种”一体两面”的设计，是我觉得整个系统最有意思的地方。这块最近还在看网上的女娲等项目，想看看有没有更好的蒸馏人格的方法。<h2 id="效果与心得"><a href="#效果与心得" class="headerlink" title="效果与心得"></a>效果与心得</h2>以上就是近期关于知识库的一些实录，有想法欢迎交流。<h2 id="常见问题"><a href="#常见问题" class="headerlink" title="常见问题"></a>常见问题</h2><h3 id="Q-Obsidian-适合程序员做知识管理吗？"><a href="#Q-Obsidian-适合程序员做知识管理吗？" class="headerlink" title="Q: Obsidian 适合程序员做知识管理吗？"></a>Q: Obsidian 适合程序员做知识管理吗？</h3>非常适合。Obsidian 的核心理念——本地 Markdown 文件、双向链接、图谱可视化——天然契合程序员的使用习惯。Markdown 语法你本来就会，文件存储在本地意味着数据完全可控、可以用 Git 做版本管理，双向链接让你能像管理代码依赖一样管理知识之间的引用关系。加上 llm-wiki 的思路，AI 可以自动帮你从散落的笔记中提取概念、建立页面和交叉引用，把零散文档变成结构化的知识网络。<h3 id="Q-LLM-Wiki-需要-GPU-吗？"><a href="#Q-LLM-Wiki-需要-GPU-吗？" class="headerlink" title="Q: LLM Wiki 需要 GPU 吗？"></a>Q: LLM Wiki 需要 GPU 吗？</h3>不需要自己部署 GPU。LLM Wiki 的核心理念是让 LLM 处理你的文本，而不是让你自己跑模型。你只需要调用大模型的 API（云端推理），用它来读取你的 Markdown 文件、提取概念、生成页面和交叉引用。这个过程走的是云端 API，不需要本地 GPU。实际上整个流程的”硬件”只需要 Obsidian 和一个能调用 LLM API 的工具（如 WorkBuddy 等 Agent）。<h3 id="Q-llm-wiki-和传统-Wiki-有什么区别？"><a href="#Q-llm-wiki-和传统-Wiki-有什么区别？" class="headerlink" title="Q: llm-wiki 和传统 Wiki 有什么区别？"></a>Q: llm-wiki 和传统 Wiki 有什么区别？</h3>传统 Wiki 需要你手动创建页面、写摘要、添加内部链接，维护成本高且难以坚持。llm-wiki 把组织成本降到了几乎为零——你只需要继续产生和收集文字内容，LLM 自动读取你的 AGENTS.md 规则，反复执行摄入、更新、审计等操作，生成结构化的交叉引用网络。换句话说，传统 Wiki 是”你组织知识”，llm-wiki 是”AI 帮你组织知识”。<h3 id="Q-知识蒸馏和人格蒸馏有什么不同？"><a href="#Q-知识蒸馏和人格蒸馏有什么不同？" class="headerlink" title="Q: 知识蒸馏和人格蒸馏有什么不同？"></a>Q: 知识蒸馏和人格蒸馏有什么不同？</h3>两者共享同一套原始素材，但目标和产出完全不同。**知识库（Wiki）**回答”我知道什么”——从笔记和读书摘录中提取客观知识，生成概念页面和交叉引用。**人格蒸馏（Personal Model）**回答”我是谁”——从创作和阅读记录中反向推导你的认知模式、表达风格和价值取向。一个向外看（结构化知识），一个向内看（建模个人认知），流程相似但方向相反。<h2 id="快速上手步骤"><a href="#快速上手步骤" class="headerlink" title="快速上手步骤"></a>快速上手步骤</h2><ol><li>安装 Obsidian：从 <a href="https://obsidian.md/">obsidian.md</a> 下载客户端，创建本地 Vault（知识库），即为一个本地文件夹。</li><li>配置 LLM Wiki：在 Vault 根目录创建 <code>AGENTS.md</code>，参照 karpathy 的 llm-wiki 思路编写知识维护规则，包括摄入（ingest）、更新、审计（audit）等流程定义。让 AI 工具读取该文件，自动从原始笔记中提取概念、建立交叉引用。</li><li>导入 Notion 笔记：在 Notion 设置中导出为 Markdown + CSV 格式，使用 Obsidian Importer 插件一键导入，或将解压的 Markdown 文件夹直接放入 Vault 目录。</li><li>接入微信读书：申请微信读书 API Key，调用 <code>/user/notebooks</code> 接口获取书籍列表，拉取划线和笔记，按章节分组输出为 Markdown 文件存入 Vault。</li><li>导入知乎与博客：使用 Playwright 脚本自动抓取知乎回答和文章；将博客 Markdown 源文件复制到 Vault。完成后让 AI 执行一次全量 wiki 摄入，生成完整的知识交叉引用网络。</li></ol>原文地址：<a href="https://lichuanyang.top/posts/18804/">https://lichuanyang.top/posts/18804/</a>

免费AI视频生成器：我如何用零成本做出带旁白字幕的多场景AI视频

2026-06-16 13:20:05

<blockquote>“解决的办法不是压制 AI，而是让它变成一种更平权的能力，让每个人都知道如何借 AI 创造更多。这也是我们公司很重要的愿景，让世界级的 AI 属于每一个人。”</blockquote>这是 Agnes AI 创始人 Bruce Yang 接受采访时说的一段话。现在很多国内的AI厂商，无论deepseek还是智谱，都在把AI的价格往下压。坦率的讲，像文字、代码的处理价格，确实已经被压到了一个相当低的价格。但视频不一样，现在做AI视频，门槛确实高得离谱——国外的 Runway、Pika 按月订阅几十美元，国内的即梦、可灵免费额度用完就按秒计费，想本地跑开源模型？一张能跑视频的显卡轻松上万。客观来讲，视频的生成，现阶段确实成本较高，让工业级的视频生成能力属于每一个人，确实不现实。但普通人也应该有一些途径能更多的去尝试、去创作，感谢Agnes开放自己的视频模型，让大家有这个机会。而这个项目只是想为了这个做一些微不足道的贡献。 <a href="https://github.com/lcy362/agnes-video-generator">Agnes Video Generator</a>（<a href="https://video.lichuanyang.top/">官网</a>）。说白了就是一个免费的AI视频生成器，不是那种”免费试用3次”的套路，是从写文案到出片、配音、上字幕，全程不花一分钱。只需要去 <a href="https://platform.agnes-ai.com/">Agnes AI</a> 注册个免费API Key就行。Agnes的视频模型，目前确实称不上完美，但我想用这么一个项目，和Agnes一起成长，为AI平权，贡献上一点微不足道的力量。<h2 id="多种玩法"><a href="#多种玩法" class="headerlink" title="多种玩法"></a>多种玩法</h2>给它一句话描述，它还你一条视频。分几种类型：简单视频。 纯粹对API的封装，用来测试效果的，接口的各种参数，基本都做成了配置。创意视频。 你写一个故事创意，比如”暗黑版青蛙王子”，AI全包：扩展故事→生成角色参考图→拆分场景→写分镜提示→逐段生成视频→配音→上字幕→拼接成片。全程10步自动跑完，你只需要等着看成片。通过预生成尾帧，可以最大限度的保障场景间视频的连贯性。文稿视频、数字人口播。 贴一篇长文章进去，自动按语音时长分段，每段生成画面，或者放一个数字人在那里念稿。用一条完整的TTS旁白和字幕串起来。做知识区内容的可以试试。各模式的详细参数和玩法，可以到<a href="https://video.lichuanyang.top/">官网</a>上看，这里就不展开了。<h2 id="跑起来很简单"><a href="#跑起来很简单" class="headerlink" title="跑起来很简单"></a>跑起来很简单</h2><figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 3 </pre></td><td class="code"><pre>git clone https://github.com/lcy362/agnes-video-generator.git cd agnes-video-generator ./start.sh </pre></td></tr></table></figure>就这三步。<code>start.sh</code> 会自动帮你建虚拟环境、装依赖、启动服务。启动后打开 <code>http://localhost:8765</code>，在页面顶部填上你的 Agnes AI API Key，选个模式，写你的创意，点生成，然后耐心等结果就行。用 Cursor 或者 Claude 这些AI Agent的话更方便，我专门为Agent做了使用说明，直接让你的Agent读项目里的Agents.md文件，它自己就能把环境搞好、把服务跑起来。<h2 id="看看效果"><a href="#看看效果" class="headerlink" title="看看效果"></a>看看效果</h2>做了几个demo,可以看看效果：<ul><li><a href="https://v.douyin.com/L4F6KdGnD6U/">暗黑版《青蛙王子》无旁白版</a> — 5个场景用关键帧衔接，全自动生成</li><li><a href="https://v.douyin.com/l2FlbF1Jdz0/">同一个故事加了旁白字幕</a> — AI配音 + 自动字幕，可以看看字幕的效果</li><li><a href="https://v.douyin.com/eSGE9KENWVU/">文稿视频</a> — 贴了篇长文进去自动分段，每段配不同画面</li></ul><h2 id="最后"><a href="#最后" class="headerlink" title="最后"></a>最后</h2>回到开头 Bruce Yang 说的那句话——「让世界级的 AI 属于每一个人」。这个项目不是什么宏大的事业，就是想让 AI 视频创作这道门开着。不用订阅、不用好显卡、不用花一分钱，你只需要一个免费的 API Key 和一台能跑 Python 的电脑。代码在 <a href="https://github.com/lcy362/agnes-video-generator">GitHub</a>，官网在 <a href="https://video.lichuanyang.top/">video.lichuanyang.top</a>。欢迎提bug。原文地址：<a href="https://lichuanyang.top/posts/22470/">https://lichuanyang.top/posts/22470/</a>

Agnes免费模型真能白嫖视频？我改造了ViMax来试试

2026-06-11 22:00:00

前阵子我在薅各种免费AI token，写了一篇关于”哪里免费去哪里薅”的文章。当时提到过，各家平台会不定期放出免费模型。结果没等多久，Agnes AI 就给了我一个惊喜：视频模型也免费了。不是文字，不是图片，是视频。<code>agnes-video-v2.0</code>、<code>agnes-image-2.1-flash</code>、<code>agnes-2.0-flash</code>，三个模型全免费，注册就送API Key，不要信用卡，不要GPU。其中 Agnes-Video-V2.0 是目前免费 agnes video 生成方案里能力最强的一个，支持多种生成模式，质量相当能打。这谁忍得住？我直接把开源框架 ViMax 改造成了 Agnes 全家桶方案，顺便把原来一些反人类的用法都优化了一遍。<h2 id="Agnes免费模型：到底给了什么"><a href="#Agnes免费模型：到底给了什么" class="headerlink" title="Agnes免费模型：到底给了什么"></a>Agnes免费模型：到底给了什么</h2>先说 Agnes 这波免费到底给了啥。在 <a href="https://platform.agnes-ai.com/">Agnes AI 平台</a> 注册之后，拿到一个 API Key，就能用三个模型：<ul><li>agnes-2.0-flash（对话模型）：写故事、编剧本、生成prompt，标准的chat接口</li><li>agnes-image-2.1-flash（图片模型）：text-to-image，生成角色参考图、关键帧</li><li>agnes-video-v2.0（视频模型）：支持 text-to-video、image-to-video、keyframes 三种模式</li></ul>API 走的是 OpenAI 兼容格式，base URL 在 <code>https://apihub.agnes-ai.com/v1</code>，对接起来非常丝滑。视频模型是异步的——提交任务拿task_id，然后轮询结果，跟大多数云端视频生成服务一个套路。关键是：这三个模型串起来，刚好覆盖了”创意 → 故事 → 图片 → 视频”的完整链路。 不需要混用别家服务，一个 API Key 搞定所有事。<h2 id="改造思路：从多供应商到-Agnes-一把梭"><a href="#改造思路：从多供应商到-Agnes-一把梭" class="headerlink" title="改造思路：从多供应商到 Agnes 一把梭"></a>改造思路：从多供应商到 Agnes 一把梭</h2>原版 ViMax 是港大开源的 Agentic 视频生成框架，设计得很通用——LLM 用一家的、图片生成用一家的、视频生成又是一家的。好处是灵活，坏处是你要管三套 API、三套认证、三套错误处理。我的改造思路很简单：既然 Agnes 三个模型全免费，那就全部换成 Agnes，一个 API Key、一个 base URL，省事。具体改了什么：编剧模块：把原来的 LLM 调用全换成 <code>agnes-2.0-flash</code>。它负责从你的一句话创意出发，生成完整故事、拆分场景、写每场景的视觉prompt，还要给每个场景生成尾帧描述。用的是 OpenAI 兼容的 chat/completions 接口，temperature 0.7，够用了。图片生成器：换成 <code>agnes-image-2.1-flash</code>（t2i）和 <code>agnes-image-2.0-flash</code>（i2i）。前者生成角色参考图，后者做场景间的过渡帧图片编辑。视频生成器：换成 <code>agnes-video-v2.0</code>，这是核心。支持三种模式——纯文字生成视频（t2v）、图片引导视频（ti2vid）、关键帧插值（keyframes）。每场景支持5到20秒，帧率24fps。改完之后，整个项目只依赖一个 API 服务商。<code>.api_key</code> 文件里写一个 key，完事。<h2 id="易用性优化：别让用户想太多"><a href="#易用性优化：别让用户想太多" class="headerlink" title="易用性优化：别让用户想太多"></a>易用性优化：别让用户想太多</h2>原版 ViMax 的用法比较”研究项目风”——参数硬编码在代码里，改个创意得改源码。这不太行，所以我在易用性上做了一堆改进。<h3 id="YAML-创意配置"><a href="#YAML-创意配置" class="headerlink" title="YAML 创意配置"></a>YAML 创意配置</h3>最大的改动是引入了 YAML 创意文件。在 <code>creatives/</code> 目录下，一个创意就是一个 <code>.yaml</code> 文件：<figure class="highlight yaml"><table><tr><td class="gutter"><pre>1 2 3 4 5 6 7 8 9 10 </pre></td><td class="code"><pre>name: "frog" idea: | 暗黑童话版青蛙王子，公主亲了青蛙之后， 青蛙变成了一个更可怕的怪物 user_requirement: | 5个场景，每个10秒，哥特暗黑风 style: "哥特暗黑童话风格" chaining_mode: keyframes video_width: 768 video_height: 1152 </pre></td></tr></table></figure>想拍新视频？写个 YAML，跑一条命令，完事。不用再碰 Python 源码了。<h3 id="一键启动脚本"><a href="#一键启动脚本" class="headerlink" title="一键启动脚本"></a>一键启动脚本</h3><code>start.sh</code> 做了一键封装：自动加载 <code>.api_key</code>、自动激活虚拟环境、自动列出可用创意、自动跑 pipeline。不传参数就列出所有创意，传个名字就直接跑：<figure class="highlight bash"><table><tr><td class="gutter"><pre>1 2 </pre></td><td class="code"><pre>./start.sh # 列出所有创意 ./start.sh frog # 跑"青蛙王子" </pre></td></tr></table></figure><h3 id="智能缓存与断点续跑"><a href="#智能缓存与断点续跑" class="headerlink" title="智能缓存与断点续跑"></a>智能缓存与断点续跑</h3>这个必须说，因为视频生成是真的慢。每个中间结果——故事文本、场景脚本、角色参考图、每场景视频——全部持久化到磁盘。跑到一半断了？重新跑同一个创意，已完成的步骤直接跳过，只生成缺失的部分。最细粒度的是视频缓存：5个场景跑了3个断了，重跑只生成剩下2个。不会从头来。<h3 id="多模态图片分析"><a href="#多模态图片分析" class="headerlink" title="多模态图片分析"></a>多模态图片分析</h3>你可以自己提供角色参考图，也可以给每个场景自定义尾帧图片。系统会通过多模态 LLM 分析这些图片的内容，把视觉信息融入故事和 prompt 生成。比如你提供一张自己画的卡通人物，系统会自动识别它的外貌特征，在后续所有场景里保持一致。<h2 id="角色一致性：两阶段锁定"><a href="#角色一致性：两阶段锁定" class="headerlink" title="角色一致性：两阶段锁定"></a>角色一致性：两阶段锁定</h2>AI视频最大的坑就是角色一致性——第一个场景是黑发妹子，第二个场景突然变成金发了。ViMax-Agnes 用了一个两阶段方案：第一阶段：先生成（或你提供）一张角色参考图。编剧模块会从故事里提取角色的详细外貌描述——体型、发型、服装、配色、标志性特征——然后让图片模型生成一张全身参考图。第二阶段：每个场景视频都以这张参考图为起始帧，通过 <code>ti2vid</code> 模式生成。视频模型从同一个视觉锚点出发，自然保持了角色的一致性。实测下来，卡通/风格化画风的一致性效果最好。写实风格的话，建议直接提供自己的参考图，比 AI 生成的更可控。<h2 id="三种场景串联模式"><a href="#三种场景串联模式" class="headerlink" title="三种场景串联模式"></a>三种场景串联模式</h2>这是我觉得改造最有意思的部分。原版 ViMax 有场景串联的概念，但我在 Agnes API 上做了三种模式的适配：<code>none</code>（独立模式）：每个场景独立生成，共用同一张角色参考图。速度最快，但场景之间没有过渡，硬切。<code>ti2vid</code>（过渡帧模式）：顺序生成，每个场景结束后提取尾帧，用 img2img 生成一张”过渡帧”，作为下个场景的起始帧。过渡比较自然，但误差会累积——前面场景的瑕疵会传到后面。<code>keyframes</code>（关键帧模式）：这是推荐方案。每个场景同时指定首帧和尾帧，让视频模型在两个关键帧之间做插值。尾帧由 AI 根据场景描述自动生成（你也可以手动指定）。这样每个场景的起点和终点都是确定的，过渡最平滑。三种模式在 YAML 里一个字段切换，不用改代码。<h2 id="实战效果"><a href="#实战效果" class="headerlink" title="实战效果"></a>实战效果</h2>跑几个创意试了一下：<ul><li>青蛙王子：5场景暗黑童话，keyframes模式，全自动生成</li><li>女孩扣篮：3场景运动主题，角色一致性保持得不错</li><li>海边舞蹈：4场景MV风格，场景过渡比较丝滑</li><li>温泉机器人：3场景治愈风，卡通风格一致性最好</li></ul>每个创意从提交到出片，主要瓶颈在视频生成——每场景大概需要几分钟等待。但因为有缓存，调试成本其实不高。<h2 id="一些-Agnes-Video-V2-0-技术细节"><a href="#一些-Agnes-Video-V2-0-技术细节" class="headerlink" title="一些 Agnes-Video-V2.0 技术细节"></a>一些 Agnes-Video-V2.0 技术细节</h2>给想深入玩的朋友补充几个实现细节：视频参数：帧数遵循 <code>8n+1</code> 规则，上限441帧。5秒121帧、10秒241帧、15秒361帧、18秒和20秒都是441帧（帧率分别是24和22fps）。图片上传：视频API需要图片URL而不是base64，所以本地图片会通过图片生成API”上传”——用 <code>agnes-image-2.1-flash</code> 做一次 prompt 为”保持图片不变”的 i2i 转换，拿到一个托管URL。如果上传失败，回退到 inline base64。重试机制：视频提交遇到429（限流）或5xx（服务端错误），会自动指数退避重试，最多5次。轮询没有超时——视频生成就是这么慢，你得等。最小依赖：整个项目只依赖5个Python包：requests、pydantic、PyYAML、moviepy、tenacity。不需要PyTorch，不需要CUDA，纯API编排层。<h2 id="写在最后"><a href="#写在最后" class="headerlink" title="写在最后"></a>写在最后</h2>Agnes 这波免费模型的诚意还是挺足的。agnes免费模型覆盖了文字、图片、视频全链路，API格式兼容OpenAI，注册门槛极低。对于想玩AI视频生成但不想烧钱的朋友来说，是个不错的入门选择。ViMax-Agnes 的改造也让我验证了一件事：当免费模型的质量够用的时候，”哪里免费去哪里薅”的策略完全可以从文本扩展到视频。 一个 API Key、一条命令、一个 YAML 文件，就能从一句话生成一个完整的多场景视频。项目开源在这里：<a href="https://github.com/lcy362/vimax-agnes">github.com/lcy362/vimax-agnes</a>，欢迎 star 和提 issue。<blockquote>2026年6月更新：本文工具已迭代为 <a href="https://github.com/lcy362/agnes-video-generator">Agnes Video Generator</a>，支持 Web UI 和多语言，功能更完善，推荐使用新版本。</blockquote>原文地址：<a href="https://lichuanyang.top/posts/65500/">https://lichuanyang.top/posts/65500/</a><h2 id="快速上手步骤"><a href="#快速上手步骤" class="headerlink" title="快速上手步骤"></a>快速上手步骤</h2><ol><li>环境准备：注册 <a href="https://platform.agnes-ai.com/">Agnes AI 平台</a> 账号，获取 API Key。确保本地已安装 Python 3.8+ 和 Git。</li><li>克隆项目：<code>git clone https://github.com/lcy362/vimax-agnes && cd vimax-agnes</code>，将 API Key 写入 <code>.api_key</code> 文件。</li><li>创建创意配置：在 <code>creatives/</code> 目录下新建 YAML 文件，定义 <code>name</code>、<code>idea</code>、<code>style</code>、<code>chaining_mode</code> 等参数。</li><li>一键生成视频：运行 <code>./start.sh <创意名称></code>，系统自动执行编剧生成、图片生成、视频生成全流程，中间结果自动缓存，支持断点续跑。</li><li>查看效果：视频输出在 <code>output/</code> 目录下，检查角色一致性、场景过渡流畅度和整体视频质量。如需调整，修改 YAML 配置后重新运行即可。</li></ol>

Mobility修改

Mobility的 RSS 预览

该作者的社会化媒体

Mobility 修改