Skip to content

2026

  • in aigc
  • 6 min read

从 CLI Agent 到本地 Agent Runtime：一套包装本地 Agent 的工程模式

Local Agent Runtime article hero

文档目标

  • 解释 Codex / Claude Code 这类 CLI Agent 如何从“终端里的命令”变成“工作流里的 Runtime”
  • 用 Agentara 作为具体例子，拆解包装本地 Agent 需要补齐的工程层
  • 总结这套模式的适用场景、风险边界和可迁移原则

阅读受众

  • 已经使用过 Codex、Claude Code 或类似 Coding Agent 的开发者
  • 想把本地 Agent 接入飞书、Web、定时任务或知识库工作流的同学
  • 希望理解 Agentara 这类项目工程本质，而不是只看安装和配置步骤的读者

0. Insight

  • 本地 Agent 的难点不只在模型：真正决定它能否进入真实工作流的，是模型外面的消息通道、会话系统、任务队列、记忆注入和可观测 UI
  • 包装层的本质是 Agent Gateway：它不替代 Codex / Claude Code 的执行能力，而是把这些 CLI Agent 包装成可交互、可持续、可拓展的本地 Agent Runtime
  • 核心抽象只有四层：统一 Runner、thread ↔ session 映射、session 级串行锁、分层上下文注入——四层补齐，CLI Agent 就成了 Runtime
  • 这套模式有明确边界：一旦远程消息能触发本地执行，权限、目录、审批、日志和可撤销性就必须先于功能扩展被设计清楚
  • 比起造一个更强的 Agent，更现实的是借力：模型和 AI CLI 仍在高速迭代，工程侧真正的价值在于把这些能力接入稳定工作流——这也是本文真正想说的

本文会用开源项目 Agentara 作为贯穿全文的例子。

它同时支持 Claude Code 和 OpenAI Codex，通过飞书收消息，通过本地服务管理会话与任务，再把 Agent 的流式输出渲染回飞书或 Web Dashboard。

本文不展开 Agentara 的安装与配置，而是借这个项目回答一个更通用的问题：

一个本地 CLI Agent，需要补上哪几层工程，才能从终端命令变成工作流里的 Runtime。

飘然地度过恐惧，以及微小的改变 26.4下旬-5月总结

0. 前言

如果说之前是失败和恐惧的声音被重新放大，

那么最近更像是在这些声音还没有完全安静的时候，试着用一种更轻的方式经过和面对它们。

首先需要明确的是恐惧并没有消失，

它依然会在我工作和生活的缝隙里出现，如同一阵潮气，悄悄漫上来：

会在复杂事项开始前出现，

会在结果不确定的时候出现，

会在需要解释判断、承接反馈的时候出现，

会在面对着这迷茫而不知如何往下走的生活时候出现.......

我在慢慢地尝试转变我的想法：

即恐惧出现之后，不一定要立刻要被它带走，也不一定要通过自责内疚来解释。

最近在一本关于心理学相关书籍上看到一个词叫，”飘然“，作者也是在书中反复强调的治疗手段。

飘然，简单来说就是一种顺其自然、不抗拒的应对态度，就和字面意思是一样的。

我想它就是我在前面所提到尝试转变的，所需要的态度，面对恐惧时：

让自身先”飘“起来之后，当然”飘“的前提是要承认自身的当下，”然“后再把注意力放回事情本身。

这段时间并不是一个完全变好的阶段，而更像是一些很小的”松动“。

而我就在这些”松动“中，就像一面充满污点的镜子，看着自己，慢慢地一点点擦拭着。

失败与恐惧的回声 26.3-4月中旬总结

0. 前言

有些结果落下来时，并不会立刻把人击中。

最先收紧的，往往不是事实本身，而是呼吸、判断，以及看待自己的方式。

后面我才慢慢意识到，这段时间真正反复回响的，并不只是一次失败，还有被它重新唤醒的另一种旧声音：恐惧。

失败把我拉回现实，让我承认差距确实存在；恐惧却总想把我从现实里拽走，在很多事情还没开始之前，就先一步占领身体和情绪。

所以回头看，这段时间更像是在同时面对两门课。

一门课，是承认失败不是对整个人的否定，而是对当前能力边界的一次校准。

一门课，是学会在心里发颤的时候，依然不把自己交给退缩，而是继续往前走一点。

  • in aigc
  • 5 min read

别再只盯着 SKILL.md 格式了：5 种更值得关注的 Agent Skill 设计模式

当越来越多 Agent 工具开始支持相似的 Skill 组织方式后，很多开发者仍然把注意力放在“外壳”上：

  • SKILL.md 怎么写
  • frontmatter 怎么配
  • references/、assets/ 目录怎么摆
  • YAML 字段要不要补齐

这些当然重要，但它们解决的，本质上只是封装格式的问题。

真正决定一个 Skill 是否好用、是否稳定、是否能复用的，往往不是它“长什么样”，而是它内部的能力结构怎么设计。

这也是 Google Cloud Tech 那篇《5 Agent Skill design patterns every ADK developer should know》真正值得看的地方：

当 Skill 的包装格式逐渐标准化之后，真正拉开差距的，不再是会不会写 Skill 文件，而是会不会设计 Skill 的内容。

文章总结了 5 种反复出现的 Skill 设计模式：

  1. Tool Wrapper
  2. Generator
  3. Reviewer
  4. Inversion
  5. Pipeline

它们不是五个零散技巧，而更像五种常见的 Agent 能力组织方式。

一切都在加速 26.1-2月总结

本来想回顾下25年的，但这一切衔接的太快了。而我也没有好好给自己留出时间。

那就顺带着3月相关的结果尘埃落定，再来抽出时间完成吧。

0. 前言

日复一日，时复一年，岁月就这样匆匆流逝……就这样逃亡着，它改变了整个世界。

它既不休息，也不停留，更不会折返。直到最终将你化为了一粒微尘。

第一次读到的时候，有一瞬间没明白自己被什么触动了。

后来想，大概是"微尘"这个词。

不是某种诗意的消逝，而是字面意义上的——被抹去，不被记得，连痕迹都没有留下。

这种恐惧我平时不太说出来，但它是真实存在的。

这两个月，时间加速的感觉不是比喻。

没有喘息的余地去问"我在哪里"，因为一停下来，已经又被推着走出去很远了。

推特永远有读不完的内容，永远有一种"你在落后"的低鸣。

我知道这种焦虑本质上是对不确定性的应激，但知道归知道，感受是另一回事。

“如果要 90 分的结果，那么就需要要付出 120 分的努力。”

听起来还有很多的事情还要做。

交代过去 25.12月总结

0. 前言

12 月对我来说，并不是发生了什么巨大转折的一个月。

更多的时候，它像是一个需要被收尾的节点。

就像这一年里的很多事情已经发生过、推进过，也在当下留下了结果和感受。

与其急着从中提炼结论、寻找答案，我更需要先做的一件事，是如实地把它们交代清楚。

对我来说，每个月抽出时间来进行总结，在这个阶段的意义并不在于给未来下判断，也不是为变化找理由，

而是让已经发生的事情有一个清晰的位置——

什么是用来交代过去的，什么是用来记录现实的，什么是需要单独拆出来、面向未来慢慢重建的。

当一些问题被清楚地记录下来，而不是反复被带入现在，它们才真正成为“过去”。

  • in aigc
  • 11 min read

Anthropic Agent Skills 完整指南：让 AI Agent 掌握专业技能的标准化方案

引言

随着大语言模型在各个领域的应用越来越广泛，如何让 AI Agent 更好地完成特定领域的专业任务成为了一个重要课题。Anthropic 推出的 Agent Skills 提供了一个优雅的解决方案——通过标准化的技能包（Skill），让 Claude 能够动态加载专业指令和资源，从而在特定任务上表现得更加专业和一致。

本文将深入介绍 Anthropic 的 Skills 项目，帮助你理解其核心价值、技术架构和实际应用。

技术准确性声明：本文中所有关键技术细节（Progressive Disclosure、高效脚本执行、环境隔离等）均基于 Anthropic 官方文档验证，包括： - Agent Skills API Guide - Agent Skills Overview - Anthropic Engineering Blog - Agent Skills

文中涉及官方文档的部分均以引用块标注，确保信息的准确性和可追溯性。

  • in aigc
  • 13 min read

跨平台 Skills 实践指南：在任何 AI 工具中使用专业技能

引言

Anthropic 的 Agent Skills 提供了一套优雅的专业技能管理方案，但最初它是 Claude 专属特性。随着社区的发展，现在有多种方案让其他 AI 编程工具（Cursor、Windsurf、Aider 等）也能使用 Skills，甚至在 LangChain、LlamaIndex 等框架中实现类似的 Skills 模式。

本文将介绍三种跨平台 Skills 实践方案，从开箱即用到深度定制，以及在实战中创建和迭代 Skills 的最佳工作流。

前置阅读：建议先阅读 Anthropic Agent Skills 完整指南 了解 Skills 的核心概念和技术架构。