一种用于验证 AI 代理协议的语言。
在浏览器中尝试 -- 无需安装。 观看 AI 代理实时运行 -- 3 个代理在已验证的协议上运行。
你的 AI 代理之间会进行交流，但没有任何机制能保证它们遵循规则。错误的发送者、错误的消息顺序、缺失的步骤——你往往只在生产环境中才会发现这些问题。
Lingua Universale (LU) 是 AI 代理对话的类型检查器。你定义协议，LU 证明其正确性，运行时环境则强制执行它。
from cervellaswarm_lingua_universale import Protocol, ProtocolStep, MessageKind, SessionChecker, TaskRequest
# Define: who sends what, to whom, in what order
review = Protocol(name="Review", roles=("dev", "reviewer"), elements=(
ProtocolStep(sender="dev", receiver="reviewer", message_kind=MessageKind.TASK_REQUEST),
ProtocolStep(sender="reviewer", receiver="dev", message_kind=MessageKind.TASK_RESULT),
))
checker = SessionChecker(review)
checker.send("dev", "reviewer", TaskRequest(task_id="1", description="Review auth")) # OK
checker.send("dev", "reviewer", TaskRequest(task_id="2", description="Oops")) # ProtocolViolation!
# ^^^ wrong turn: reviewer must send next协议规定接下来由审核员操作。运行时环境会阻止其他操作。这并非因为你信任代码，而是因为会话类型使得违规操作成为不可能。
Related MCP server: edict-lang
pip install cervellaswarm-lingua-universale或者先尝试一下：Playground（通过 Pyodide 在浏览器中运行）。
protocol DelegateTask:
roles: supervisor, worker, validator
supervisor asks worker to execute analysis
worker returns result to supervisor
supervisor asks validator to verify result
when validator decides:
pass:
validator returns approval to supervisor
fail:
validator sends feedback to supervisor
properties:
always terminates
no deadlock
no deletion
all roles participate然后验证它：
lu verify delegate_task.lu [1/4] always_terminates ... PROVED
[2/4] no_deadlock ... PROVED
[3/4] no_deletion ... PROVED
[4/4] all_roles_participate ... PROVED
All 4 properties PASSED.数学证明。不是那种今天通过明天失败的测试。
特性 | 描述 |
完整编译器 | 词法分析器、解析器（64 条规则）、AST、契约检查器、Python 代码生成 |
9 个已验证属性 |
|
20 个标准库协议 | AI/ML、业务、通信、数据、安全——开箱即用 |
Linter + 格式化工具 |
|
LSP 服务器 | 诊断、悬停提示、补全、跳转到定义、格式化 |
VS Code 扩展 | |
交互式聊天 |
|
浏览器 Playground | 立即尝试 -- 检查、Lint、运行、聊天 |
Lean 4 桥接 | 生成并验证数学证明 |
REPL |
|
项目脚手架 |
|
37 个模块。3979 个测试。零外部依赖。纯 Python 标准库。
lu check file.lu # Parse and compile
lu verify file.lu # Formal property verification
lu run file.lu # Execute
lu lint file.lu # 10 style and correctness rules
lu fmt file.lu # Zero-config auto-formatter
lu chat --lang en # Build a protocol conversationally
lu demo --lang it # See the La Nonna demo
lu init --template NAME # Scaffold from stdlib templates
lu visualize file.lu # Generate Mermaid sequence diagram
lu mcp-audit --manifest t.json # Audit MCP server protocols
lu repl # Interactive REPL
lu lsp # Start LSP server将协议验证添加到你的 GitHub Actions 工作流中：
# .github/workflows/lu-check.yml
on:
push:
paths: ["**/*.lu"]
jobs:
lu-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v6
with:
python-version: "3.11"
- run: pip install cervellaswarm-lingua-universale
- run: lu lint protocols/
- run: lu verify protocols/违规时退出代码为非零值——适用于任何 CI 系统。
LU 基于 多方会话类型 (Honda, Yoshida, Carbone -- POPL 2008)。会话类型将通信协议描述为类型：如果两个进程遵循相同的会话类型，它们就不会死锁，消息不会以错误的顺序到达，并且对话总是会终止。
流水线：
.lu source → Tokenizer → Parser → AST → Spec Checker → Lean 4 Proofs → Python Codegen
↓
PROVED or VIOLATEDLU 不会取代你的 AI 代理框架。它让框架变得安全。就像 TypeScript 之于 JavaScript——你保留了你的工具，但增加了保证。
LU Debugger -- 实时 Web 应用：3 个 AI 代理（客户、仓库、支付）在已验证的 OrderProcessing 协议上进行通信。点击 "Break" 查看实时拦截的协议违规。 源代码。
查看 examples/ 目录：
或者尝试 交互式 Colab 笔记本 -- 2 分钟，零配置。
Lingua Universale 是 CervellaSwarm 的核心项目。我们还发布了以下 Python 包：
包 | 功能 |
基于 AST 的代码理解（tree-sitter, PageRank） | |
Claude Code 代理的生命周期钩子 | |
代理定义模板和团队配置 | |
确定性任务路由与验证 | |
多代理进程管理 | |
跨对话的持久会话上下文 | |
不可变事件日志与审计追踪 | |
自动化质量检查与评分 |
全部采用 Apache 2.0 协议，支持 Python 3.10+，经过测试并有文档记录。
我们欢迎贡献！请参阅 CONTRIBUTING.md 获取指南。
错误报告： GitHub Issues
安全： 请参阅 SECURITY.md 进行负责任的披露
Apache License 2.0 -- 请参阅 LICENSE。
版权所有 2025-2026 CervellaSwarm 贡献者。
Lingua Universale -- AI 代理的已验证协议。
Playground | LU Debugger | PyPI | VS Code | 博客 | Colab 演示
Verify the formal safety properties declared in a .lu protocol.
Runs the static property checker (Layer 1) on all protocols found in
the source. Optionally, if Lean 4 is installed, also runs formal
verification (Layer 2).
Args:
protocol_text: Full .lu protocol definition text including a
"properties:" block, e.g.:
" properties:\n"
" always terminates\n"
" no deadlock\n"
" all roles participate\n"
Returns:
JSON string with:
ok (bool), protocols (list of protocol results), summary (dict).
Each protocol result has: protocol_name, all_passed, results (list).
Each result has: kind, verdict, evidence, params.
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses running the static checker on all protocols and the optional Lean verification, including the prerequisite of Lean installation. No contradictions or missing critical behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an intro, argument explanation, and return value specification. It is relatively concise and front-loaded, though slightly lengthy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema exists), the description is complete. It explains the input format, optional behavior, and return structure in sufficient detail. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining the 'protocol_text' parameter in detail, including example format and requirement for a 'properties' block. This adds significant meaning beyond the schema which only defines it as a string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying formal safety properties in .lu protocols. It specifies static checking and optional Lean verification, distinguishing it from sibling tools like lu_list_templates, lu_load_protocol, and lu_verify_message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to verify properties) and mentions optional Lean verification if installed. It does not explicitly exclude scenarios, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Lingua Universale standard library protocol templates.
The standard library contains 20 verified protocols across 5 categories:
communication, data, business, ai_ml, security.
Args:
category: Optional filter. One of: communication, data, business,
ai_ml, security. Leave empty to list all templates.
Returns:
JSON string with:
ok (bool), templates (list), category_filter (str), total (int).
Each template has: name, category, description.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the return structure (JSON with ok, templates, category_filter, total) and the number of templates and categories. It does not cover error handling or edge cases, but for a read-only list tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, each sentence adds value. It is concise yet complete, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (list with optional filter), the description covers all necessary context: purpose, parameter usage, and return format. No additional information is needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by specifying the allowed values for the category parameter and explaining the default behavior (empty lists all). This adds essential meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available Lingua Universale standard library protocol templates, specifying the resource and action. It distinguishes from sibling tools (check, load, verify) by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear guidance on using the optional category filter, including the list of allowed categories and that leaving it empty lists all. However, it does not explicitly state when not to use this tool versus alternatives, though the context of siblings makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Lingua Universale (.lu) protocol definition.
Accepts the full text of a .lu file and returns the parsed protocol
structure: name, roles, steps, choices, and declared properties.
Args:
protocol_text: Content of a .lu file, e.g.:
"protocol RequestResponse:\n"
" roles: client, server\n"
" client asks server to process request\n"
" server returns response to client\n"
" properties:\n"
" always terminates\n"
" no deadlock\n"
Returns:
JSON string with keys:
ok (bool), protocol_name (str), roles (list[str]),
steps (list), properties (list), error (str on failure).
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the operation is a parsing action with no side effects, includes error handling, and fully covers behavior since no annotations are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with Args and Returns sections, including a helpful example, though slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple tool with one parameter and no output schema, covering input format and output keys.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description provides a clear example and explains the input format (full text of .lu file), adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it parses a .lu protocol definition and returns the parsed structure, clearly differentiating from sibling tools like lu_check_properties and lu_list_templates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for loading a protocol from text but lacks explicit guidance on when to use alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify whether a message is valid in the context of an ongoing session.
Replays the existing message history against the protocol, then checks
whether next_message is the expected next step.
Args:
protocol_text: Full .lu protocol definition text.
messages: List of already-sent messages, each a dict with keys:
sender (str), receiver (str), action (str).
Actions are LU action names: "asks", "returns", "sends",
"proposes", "tells". These match the verbs in .lu source files.
next_message: The message to validate, same format as above.
Returns:
JSON string:
On success: {"valid": true, "step": N, "next_expected": "..."}
On violation: {"valid": false, "violation": "...", "expected": "...", "got": "..."}
On error: {"valid": false, "error": "..."}
Example:
protocol_text = "protocol Ping:\n roles: a, b\n a asks b to ping\n b returns pong to a\n properties:\n always terminates\n"
messages = [{"sender": "a", "receiver": "b", "action": "asks"}]
next_message = {"sender": "b", "receiver": "a", "action": "returns"}
# Returns: {"valid": true, ...}
| Name | Required | Description | Default |
|---|---|---|---|
| protocol_text | Yes | ||
| messages | Yes | ||
| next_message | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the replay-and-check algorithm, parameter semantics, and full return format. It does not mention side effects, but as a verification tool, none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose sentence, then detailed argument descriptions, return format, and example. Slightly lengthy due to example but front-loaded and each section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 required nested parameters with 0% schema coverage and an output schema described in text, the description provides complete information: argument formats, valid actions, return types, and a concrete example. An agent can invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully compensates by explaining each parameter: protocol_text is .lu protocol text, messages list with required keys, next_message same format, with example action values. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies if a message is valid given a protocol and message history, using verbs like 'verify' and 'replays'. It is distinct from siblings that check properties, list templates, or load protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the context ('in the context of an ongoing session') and the process (replaying history, checking next step). It does not explicitly state when not to use or alternatives, but siblings are sufficiently different, making intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0lu_check_propertieslu_list_templateslu_load_protocollu_verify_messageScored across 4 tools
Each tool has a distinct purpose: parsing, message verification, property checking, and template listing. No overlap in functionality; agents can easily select the right tool for their task.
Names follow a consistent 'lu_' prefix and verb_noun pattern (load_protocol, verify_message, check_properties, list_templates). Minor deviation: 'load_protocol' could be 'parse_protocol' but still clear and consistent.
With only 4 tools, the server is slightly under the typical 3-15 range, but this is appropriate for a niche protocol validation domain. The tools cover the core needs without bloat.
The server covers parsing, verification, property checking, and template listing, but misses a 'simulate' or 'validate full session' tool. Gaps exist for agents needing end-to-end protocol simulation or editing, but core workflows are supported.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
The team layer for AI coding agents: shared contracts, collision alerts, E2EE sessions.
Pre-execution governance for AI agents. Deterministic PASS/FAIL/REVIEW verdicts, replayable proof.
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
