Skip to content

All Blog

从 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. 前言

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

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

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

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

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

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

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

别再只盯着 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 月对我来说,并不是发生了什么巨大转折的一个月。

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

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

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

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

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

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

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

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

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

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

引言

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

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

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

通用 CodeAgent 的落地实践:从架构到关键设计点

引言

如何构建一个真正能在开发流程中派上用场的 CodeAgent?不是那种回答一次就结束的代码问答机器人,而是能够理解任务、拆解步骤、操作文件、运行测试、并在遇到问题时自主调整的开发助手。

这个问题看似简单,实际落地时却会遇到大量工程细节:Agent 的状态如何建模?工具该怎么设计才能让模型稳定调用?上下文窗口有限的情况下如何让 Agent "看到"足够的信息?当 Agent 的一次操作出错时,系统该如何恢复?

这篇文章试图分享我们在这个过程中积累的一些经验。技术选型上,我们使用的是 LangGraph 和 LangChain 1.0,配合 Textual TUI 和 MCP 工具协议。但我们更希望讨论的是设计思路本身——这些思路在其他框架和工具链下同样适用。

不同的归因 25.11月总结

0. 前言

这段时间在复盘一些事情的时候,发现自己经常会陷入两种归因:

一种是过于简单的叙事,比如“我就是不行”“对方太过分了”。

另一种是太绝对的结论,听上去很有道理,但对下一步该怎么做没什么帮助。

后来我开始有意识地问自己:

同样一件事,有没有一种归因方式,既能更接近真实的根因,又能指导我接下来该怎么做?

科学评测 AI 应用,分离“随机性”与“真实能力”

摘要: 本文提出了一种“N-Fold 稳定性优先”的评测框架。它通过 N 次重复实验,引入标准差 (StdDev)案例稳定性 (Case Stability Rate) 两个核心指标,帮助团队科学地量化和剥离 AI 模型的输出随机性,从而准确定位“稳定失败”的案例,实现可控、可迭代的工程优化。

概括的幻觉 25.9月下旬-10月总结

0. 前言

随着经历的增加,我开始学会用“概括”来看待事情。

它带来一种清晰感——好像能用一句话,把复杂的经历和情绪都装进去。

可慢慢地,我发现这种清晰,其实是一种幻觉。

概括让我们以为理解了,

但更多时候,它会让我失去继续思考,也忽略当下的情况。

那些被我总结过的道理,总是很难带入当下的场景和体验。

它们像是事后才出现的反应,

到了需要它们的时候,它们往往像失去了声音一般。

总是误以为自己通过概括获得了理解, 实际上却失去了理解的细节。

真正的理解,也许不是提炼出一句话,

而是回到那件具体的事情里,重新感受当时的自己。

不急着下结论,不急着解释,

只是去看——那一刻我究竟在想什么,又是怎么走到这里的。

力不从心 25.8-9月中旬总结

0. 前言

现实就是这样,不断地为我纠正,以前认为最糟糕的时刻还并不是最糟糕的。

这将近一个半月的时间,应该是今年平均表现最差和最为混乱失衡的一个周期,是投入“个人时间”上最少的周期。

各种不好的现象和习惯都让我变得不太像之前的“自己”,能感受到自己的生命力在一点点流失。

仅仅是维持好正常的状态和表现,就已经变得异常艰难。

很多事情,很多自己,很多想要看清的思想和感情,很多想要得到的问题和答案,力不从心。就这样安慰自己。

随着惯性 25.7月总结

0. 前言

7月对于我来说更多就像是一个朦胧的梦境,偶尔想不起自己所做的事

弥漫着的大雾让我难以看清,随着我身体和精神上的惯性行走着

时好时坏,时而美丽又时而邪恶,面对无法稳定的自己会感到麻木

状态的起伏也如玻璃一般,积攒着,忍耐着,然后在某个受力点,全部破碎

我想,那既然这样,那索性随着惯性继续吧,让一切自然发生,要尽量照顾好自己

当一切秩序被打破 25.5-6月总结

0. 前言

当每个人提到自己的焦虑和压力时,所体验到的份量:

或许大到能把人推进暗黑深渊而无法自拔,又或许小到也只是随意闪过的念想。

就是这样越简单的情绪描述,往往也是越难以控制和抗争的对象。

这两个月对我来说印象和感受最深的,就是焦虑和压力,而与之伴随的生活也总是被打乱和折磨。

我想,当一切秩序被打破,当所有精神被摧毁,残存下来的我会变成什么样子。