CangjieMagic: 华为仓颉社区开源的 LLM Agent 开发框架 (2025.03),基于仓颉语言原生构建 lambdagentpaas: 基于 λA 类型化 Lambda 演算的 Agent 编程平台,三篇论文支撑
Sources:
| 维度 | CangjieMagic | lambdagentpaas |
|---|---|---|
| 一句话定位 | 仓颉语言原生的 Agent 开发框架 | Agent 编程语言 + 静态安全平台 |
| 核心能力 | 让开发者用仓颉语言快速构建 Agent | 让 Agent 组合有数学保证 |
| 宿主语言 | 仓颉 (Cangjie) | Python |
| 理论基础 | 无形式化理论 | 三篇论文 (λA 类型系统 + 操作语义 + 效果系统) |
| 平台 | HarmonyOS + Windows + macOS + Linux | 服务器 + 本地 + PaaS |
| MCP 支持 | 原生 MCP 协议 | MCP Client + MCP Server |
| 开源时间 | 2025.03 | 研究项目 |
// @agent: 定义智能体
@agent[
model: "deepseek:deepseek-chat",
tools: [search_web, read_file],
mcp: [stdioMCP, httpMCP],
rag: { source: "./docs/manual.pdf", mode: "static" },
description: "一个通用助手",
temperature: 0.7,
executor: "tool-loop",
memory: true,
enableToolFilter: true,
dump: true,
]
class AssistantAgent {
// @prompt: 系统提示词 (支持 CRISPE 模式)
@prompt[pattern: "CRISPE"] (
capacity: "你是一个专业的技术顾问",
insight: "深入理解软件架构设计",
statement: "请提供清晰、准确的技术建议",
personality: "严谨、务实",
experiment: "尝试从多角度分析问题",
)
// @tool: 定义工具
@tool
func searchDocument(query: String): String {
// 搜索文档
}
// 默认对话方法
func chat(question: ToString): String
}
// 多智能体协同 — 三种操作符
let result1 = agentA | agentB // 自由协同 (FreeGroup)
let result2 = agentA |> agentB |> agentC // 线性协同 (LinearGroup, 管道)
let result3 = leader <= [worker1, worker2] // 主从协同 (LeaderGroup)
# Lambda 项构建
assistant = Lam("assistant", "你是一个专业的技术顾问", model="deepseek-chat")
search = Tool("search", search_document)
reader = Tool("read", read_file)
# 组合: 管道 (≡ CangjieMagic 的 |> 线性协同)
pipeline = assistant >> search >> reader
# 并行 (≡ CangjieMagic 的 | 自由协同)
parallel = Pair(agentA, agentB)
# 主从 (≡ CangjieMagic 的 <= 主从协同)
handoff = Handoff(
selector=leader,
registry={"worker1": worker1, "worker2": worker2},
)
# 额外构造 (CangjieMagic 没有的)
loop = Loop(body, condition, max_steps=20) # Y 组合子
guard = Guard(agent, validator=is_valid, retry=3) # 输出验证
route = Route(classifier, {"code": coder, "doc": writer}) # 多路分发
# YAML 声明式
agentId: assistant
type: react
model: { provider: deepseek, name: deepseek-chat, temperature: 0.7 }
systemPrompt: "你是一个专业的技术顾问"
mcp: { localTools: [search, read, terminate] }
runtime: { engine: cek, costBudget: 5.00 }
这是两个框架最可比较的部分。
| 模式 | CangjieMagic 操作符 | lambdagent 构造 | 形式化保证 |
|---|---|---|---|
| 自由协同 | agentA \| agentB (FreeGroup) |
Pair(A, B) / Par(A, B, C) |
Pair 汇合定理 (Prop. 30) |
| 线性协同 | A \|> B \|> C (LinearGroup) |
A >> B >> C (Compose) |
结合律 (Thm. 36) + T-Compose 类型检查 |
| 主从协同 | leader <= [workers] (LeaderGroup) |
Handoff(leader, registry) |
动态路由 + 类型兼容检查 |
| 循环 | 未公开 | Loop(body, cond, n) |
终止性定理 (Thm. 5.4) |
| 审查 | 未公开 | Guard(agent, P, k) |
精化类型 {x:B\|P(x)} |
| 多路分发 | 未公开 | Route(classifier, routes) |
T-Route 穷举检查 |
| 群组讨论 | 未公开 | GroupChat(agents, scheduler) |
N 智能体 Y 组合子 |
| 消息通道 | MCP 协议 | Channel + Send + Receive |
π-演算通信 |
CangjieMagic 的优势: 操作符语法极其简洁—— |、|>、<= 三个符号覆盖三种协同模式,学习成本几乎为零。
lambdagent 的优势: 构造种类多 (11+5 vs 3),每个构造有形式化定理保证。CangjieMagic 的 | 没有并行安全检查,|> 没有类型兼容检查。
| | CangjieMagic @prompt | lambdagent systemPrompt | |--|---------------------|----------------------| | 结构化 | CRISPE 模式 (Capacity/Insight/Statement/Personality/Experiment) | 自由文本 | | IDE 支持 | 仓颉 IDE 可解析 pattern 字段 | VS Code 扩展 (基础 lint) | | 编译检查 | 模式字段存在性检查 | 26 条 lint 规则 |
CangjieMagic 的 CRISPE 模式是个好设计——把 prompt 拆成 5 个维度,比自由文本更结构化、更可审查。lambdagent 的 systemPrompt 是自由文本,可以考虑借鉴。
| | CangjieMagic @tool | lambdagent Tool |
|--|-------------------|----------------|
| 定义方式 | @tool func name(args): ReturnType | Tool("name", fn) |
| 类型 | 仓颉静态类型 | Paper III τ₁ →^{io} τ₂ |
| 验证 | 仓颉编译器类型检查 | ValidatedTool + JSON Schema |
| 权限 | 未公开 | GatedTool + 60+ 危险命令检测 |
| MCP 工具 | mcp: [stdioMCP, httpMCP] | MCP Client 自动发现 |
| 内置数量 | 未公开 | 52 个 |
| 能力 | CangjieMagic | lambdagentpaas |
|---|---|---|
| 编译时类型检查 | 仓颉基础类型 | T-Compose: output(f) <: input(g) |
| 编译时成本预测 | 无 | 分级类型 (p, t, l, m) |
| 终止性保证 | 无 | 定理 5.4: fix_n 在 n 步终止 |
| 并行安全证明 | 无 | 命题 30: Pair 汇合 |
| lint 规则 | 无 | 26 条 |
| 效果隔离 | 无 | Production/Test/Trace Handler |
| 成本熔断 | 无 | CEK Yield 逐步监控 |
| 代数优化 | 无 | 6 条代数定律 |
这是最大的差距。CangjieMagic 的三种协同操作符(| |> <=)没有任何形式化保证:
A | B 并行时两个 Agent 写同一个状态怎么办?没有检查A |> B 管道中 A 的输出类型和 B 的输入不兼容?仅靠仓颉基础类型检查(String→String)leader <= workers 没有终止条件怎么办?没有检测CangjieMagic 架构:
@agent/@prompt/@tool 宏装饰器
↓
仓颉编译器 (类型检查)
↓
Agent Runtime (tool-loop/naive 执行器)
↓
MCP 协议 (工具通信)
↓
LLM Provider (OpenAI/Ollama/DeepSeek/盘古)
lambdagentpaas 架构:
YAML / Python DSL
↓
from_config 编译器 (YAML → λA 项)
↓
Static Analysis (lint + type_check + cost_predict + store_check) ← CangjieMagic 没有
↓
Dual Engine (Recursive / CEK / Adaptive) ← CangjieMagic 没有 CEK
↓
MCP 协议 + PaaS API + MCP Server
↓
LLM Provider (7 个) + LLM Wiki 知识层 ← CangjieMagic 没有 Wiki
关键差异:lambdagentpaas 在编译器和运行引擎之间多了一层静态分析,这是 CangjieMagic 没有的。
| 能力 | 重要性 | lambdagent 能否补 |
|---|---|---|
| 仓颉语言原生 | 高(HarmonyOS 生态) | 不补(不同语言) |
操作符语法 (\| \|> <=) |
中(开发体验) | 可以在 Python 中用 \| >> 运算符(已有 >> 和 \|) |
| CRISPE prompt 模式 | 中(结构化 prompt) | 可借鉴,给 @prompt 加结构 |
| 端侧 + 桌面全平台 | 高(移动生态) | 暂不需要 |
| dump 调试 | 低 | 已有 CEK trace(更强) |
| 能力 | CangjieMagic 能否补 | 壁垒 |
|---|---|---|
| T-Compose 类型检查 | 需要重新设计类型系统 | 高——需要论文级理论 |
| 成本预测 (分级类型) | 概念上不存在 | 高——需要效果代数 |
| 终止性定理 | 需要 Y 组合子理论 | 高 |
| 并行安全 (Pair 汇合) | 需要集合论分析 | 高 |
| 6 条代数定律 | 需要操作语义推导 | 高 |
| CEK Machine | 需要抽象机理论 | 中——工程实现可行 |
| LLM Wiki 知识层 | 可以补 | 低——工程模式 |
| 跨框架 lint | 做不到(绑定仓颉) | 高——lambdagent 跨语言 |
| 6 个 Pattern 库 | 可以补 | 低 |
CangjieMagic 最吸引人的是三个操作符。把它们和 lambdagent 的对应物放在一起:
CangjieMagic lambdagent 形式保证
────────── ────────── ────────
A | B Pair(A, B) Prop. 30 汇合
自由协同 并行对 store independence
FreeGroup Church pair 调度无关性
→ 没有安全检查 → 编译时检查写集合不相交
A |> B |> C A >> B >> C Thm. 36 结合律
线性协同 函数组合 T-Compose 类型检查
LinearGroup Compose 成本累加公式
→ 没有类型兼容检查 → 编译时 output(A) <: input(B)
leader <= [w1, w2] Handoff(leader, {w1, w2}) 类型兼容检查
主从协同 动态委托 fallback 支持
LeaderGroup π-演算 name passing 运行时注册/注销
→ 没有终止条件 → leader 可以是 LLM Route
(不存在) Loop(body, cond, n) Thm. 5.4 终止性
Y 组合子 成本 = g^n
(不存在) Guard(agent, P, k) 精化类型
输出验证 + 重试 1-(1-p)^k
(不存在) Route(classifier, routes) T-Route 穷举
多路分发 编译时分支检查
(不存在) GroupChat(agents, scheduler) N 智能体 Y_n
群组讨论 max_rounds 终止
CangjieMagic 的 3 个操作符 ≈ lambdagent 的 3/11 个构造。lambdagent 多出的 8 个构造(Loop/Guard/Route/GroupChat/Channel/Send/Receive/Memory)覆盖了 CangjieMagic 无法表达的场景。
是竞品,但在不同维度竞争。
CangjieMagic 的竞争力:
仓颉语言原生 → HarmonyOS 开发者必用
操作符极简 → 5 分钟上手
全平台 → 端侧 + 桌面 + 即将支持 Android/iOS
华为生态 → 亿级设备
lambdagentpaas 的竞争力:
形式化证明 → 数学保证 Agent 安全
跨平台跨框架 → 不绑定任何语言/生态
静态分析 → 编译时发现问题
LLM Wiki → 知识编译而非 RAG
交集:
两者都是 "Agent DSL" → 都认为 Agent 需要专用语言
都支持 MCP 协议 → 工具生态互通
都有多智能体协同 → 但安全保障差距巨大
给 CangjieMagic 做安全层:
CangjieMagic 开发者写完 Agent:
@agent[model: "deepseek:deepseek-chat"] class MyAgent { ... }
let pipeline = agentA |> agentB |> agentC
导出为 lambdagent 可分析的格式:
agentA |> agentB |> agentC
→ Compose(Lam("A"), Compose(Lam("B"), Lam("C")))
lambdagent 静态分析:
→ lint: "agentC 没有 terminate 工具"
→ type_check: "agentA 输出 Json, agentB 期望 Str → 不兼容"
→ cost_predict: "3 步管道 × DeepSeek → $0.012/次"
→ store_check: "agentA | agentB → 两者都修改 userState → 冲突"
这给 CangjieMagic 加了它完全没有的安全保障层
而且不需要改 CangjieMagic 一行代码
CangjieMagic 用 3 个操作符让 Agent 协同变得极简(| |> <=),lambdagentpaas 用 11 个 λA 构造让 Agent 协同变得安全(类型检查 + 终止性 + 并行安全)。 前者是"开发速度"的极致,后者是"运行安全"的极致。最理想的组合是用 CangjieMagic 写 Agent、用 lambdagent 检查 Agent——快速开发 + 安全保障。