用仓颉语言写 Coding Agent：cjh 是怎么实现的

TL;DR 速览

• cjh 定位：仓颉语言原生的 Coding Agent，据公开报道刚出现
• 语言底子：静态类型 + 内存安全，天生适合写工具链
• 架构本质：Harness 驾驭工程在仓颉生态的落地方案
• 我的判断：国产语言 + AI 编程，路径成立但生态是短板

2026 年 8 月底，一个叫 cjh 的仓颉语言 Coding Agent 在开发者社区里传开。据公开报道，这是仓颉生态里冒出来的原生 AI 编程工具，走的不是「套壳大模型」路线，而是用仓颉语言本身写 Agent 框架。消息一出，不少人问同一个问题：仓颉写 Agent，到底靠不靠谱？

我的直觉是，这事有意思，但别急着吹。国产语言做 AI 编程工具，成败不在一两个炫技 demo，而在工具链能不能落地。这篇文章不吹不黑，把 cjh 能聊清楚的地方聊清楚，聊不清楚的，我直接标「以官方文档为准」。

仓颉为什么适合写 Agent

先补一点背景。仓颉是华为 2020 年对外公开的编程语言，定位是「面向全场景」——尤其跟鸿蒙生态绑定。它最大的几个卖点：静态类型、内存安全、现代化的并发模型。

静态类型对写 Agent 意味着什么？Coding Agent 的核心是让模型输出结构化动作，再交给工具去执行。动作的输入输出如果类型不明确，模型一次「幻觉」就可能让工具链崩溃。静态类型相当于给每一步动作套了层校验，模型给错参数，编译期就能拦住，而不是运行时炸掉。

内存安全更好理解。Agent 会长时间驻留、反复调用外部工具、处理大段代码文本，任何一处越界或悬垂指针，都会让整个会话挂掉。仓颉的引用与借用机制，从设计上把这些坑堵住了一部分。

并发这一块，我单独说。Coding Agent 干活很少是单线程的：一边等模型流式返回，一边跑文件检索，一边执行命令。仓颉的并发模型如果做得干净，Agent 的调度层就能写得更薄。当然，具体 API 怎么用，以官方文档为准，我不在这里编语法。

还有两个容易被忽略的点：模式匹配和错误处理。Coding Agent 要处理的动作类型非常多——改文件、跑测试、查文档、调命令，每种返回结构都不一样。模式匹配能把这种多分支的类型分派写清爽，不用堆一长串 if-else。错误处理更关键，Agent 每一步都可能失败，语言强制显式处理错误，就逼着框架把失败路径也设计清楚。很多 Agent 跑飞，恰恰是失败路径没处理。

拿个比喻收尾：写 Agent 框架像造流水线，模型是下单的客户，工具是干活的机器。客户会下错单，机器会卡料，仓颉这套静态类型加内存安全，等于装了质检和保险丝，错单早拦截，短路早跳闸。

cjh 架构拆解：Harness 的仓颉落地

cjh 这个名字，社区里普遍解读为「Cangjie Harness」的缩写。Harness 这个词，在 AI 编程圈已经是个通用概念，指的是驾驭大模型的那层「缰绳」——负责把模型、工具、环境、上下文串成一个闭环。

拆开看，一个 Coding Agent 的 Harness 大致分四层：上下文层（收集代码、文件、历史）、规划层（把任务拆成步骤）、执行层（调用工具、跑命令）、校验层（检查结果、决定要不要回滚）。这四层里，执行层和校验层是最吃语言底子的地方，恰好是仓颉想发力、也最能体现静态类型和内存安全优势的部分。

每一层展开说几句。上下文层要解决「喂给模型的东西准不准、全不全」，代码检索、依赖图、历史会话，数据量大且频繁增删，吃的是内存管理和数据结构。规划层偏算法，把一句模糊需求拆成可执行步骤，拼的是模型和提示词设计。执行层是风险最集中的地方，工具调用要经过序列化、参数校验、超时、取消，任何一环出错都要能兜住。校验层是「结果对不对」的收口关，决定要不要回滚。

cjh 目前能确认的，是它站在仓颉生态内部做这套闭环。跟「用 Python 粘一堆 API」的路线比，它更接近「用系统级语言写一个可长期维护的 Agent 框架」。这种选择的代价也很明显：生态里的现成轮子少，很多东西得自己造。以官方文档为准的前提下，我对它的具体模块划分不下死结论，但从公开信息看，方向是清晰的。

Harness 这个词本意是「马具、缰绳」。好的 Harness 不是替马跑，而是让马跑得稳、跑得可控。cjh 定位准确的话，该做的是把仓颉生态里「模型 + 工具 + 项目」之间的缰绳收紧，而不是再造一个大模型。

跟 Claude Code / Codex 差在哪

把 cjh 放到主流 Coding Agent 旁边比一比，差距和差异都一目了然。

维度	cjh（仓颉）	Claude Code	Codex
实现语言	仓颉	TypeScript	TypeScript
生态成熟度	起步期	成熟	成熟
工具链完备度	偏弱	强	强
语言安全特性	静态类型/内存安全	依赖运行时	依赖运行时
目标场景	仓颉/鸿蒙生态	通用	通用

这张表不是要证明谁强谁弱，而是说清楚 cjh 的位置：它不跟 Claude Code 拼通用性，而是赌「自家生态内的深度集成」。Claude Code、Codex 的护城河是海量工具和社区插件，cjh 现在连地基都还在打，谈赶超为时尚早。

细看实现语言的差异挺能说明问题。Claude Code 和 Codex 选 TypeScript，图的是 npm 生态的现成库和编辑器插件里的灵活性。仓颉选自家语言，图的是长期维护成本和安全性，代价是周边几乎都得从头写。两条路线没有对错，一个求快，一个求稳。

但换个角度，仓颉生态里现在缺的正是一个原生 Agent。如果 cjh 能把鸿蒙开发、仓颉项目的辅助编程做深，它就有一个别人进不来的入口。这种「生态原生」的粘性，通用工具给不了。

想上手，从哪下手

对想试试的开发者，我的建议是分三步，别一上来就想改造框架。

先跑起来。不管 cjh 的安装入口是命令行还是插件，先让它在你本地的仓颉项目里动起来，验证它能不能读懂仓颉代码、给出可编译的修改建议。具体的安装命令和参数，以官方文档为准，别照搬二手教程。

再盯执行层。观察它调用工具、执行命令时的日志，看类型错误是不是在早期就被拦住了。这是判断「仓颉底子到底有没有用上」的关键观察点。

想把它的思路复刻一遍，可以按下面这个流程自己搭个最小闭环，具体语法以官方文档为准，我只给逻辑示意：

循环 {
  1. 收集上下文：当前文件、依赖、最近 diff
  2. 拼提示词，请求模型，拿回「动作序列」
  3. 对每个动作做类型校验：参数对不对、工具在不在白名单
  4. 执行动作，捕获异常与超时
  5. 校验结果：测试通过则提交，失败则回滚并反馈给模型
}

这个循环看着朴素，但每一步都藏着一堆工程细节。你在搭的时候，会发现自己踩的坑，就是 cjh 团队当初踩过的坑。

第三步才是贡献。如果 cjh 是开源的，从一个类型标注错误或一个工具适配补丁入手，比写一篇评测有价值得多。国产语言生态能不能起来，靠的就是这种「顺手修一个」的参与。

我的判断：国产语言 + AI 编程，路径成立吗

我的立场很明确：路径成立，但窗口期不等人。

说它成立，是因为 AI 编程工具本质是「语言能力 + 工具链」的组合，而仓颉在语言能力这块有真东西，不是营销包装。用一门静态类型、内存安全的语言去写 Agent 框架，工程上的合理性是站得住的。

说它悬，是因为 Coding Agent 的竞争早就不在「谁写得漂亮」，而在「谁的工具多、谁的用户多、谁的数据反馈快」。仓颉生态的用户基数和开源活跃度，跟主流生态差着数量级，一个 demo 再惊艳，缺了真实项目和反馈也走不远。

所以我对 cjh 的期待，不是它明天就能打过 Claude Code，而是它能不能成为仓颉生态里那个「自己人写的、真正好用的」Agent。国产编程语言要想在 AI 时代站稳，靠的正是不停有人做这种脏活累活。cjh 是起步，但不是终点。