内容
# TETA+PI 协议 (Θ+π)
> 代理互联网的中心信任注册表。
> 如同 ICANN 之于域名，如同 CA/Browser Forum 之于 SSL。
**TETA+PI** 验证任何实体——企业、记者、创作者或组织——以便 AI 代理可以信任它们正在与之交互的对象。
## 问题
代理协议（MCP、A2A）处理连接性，但没有一个协议处理身份验证、验证或来源验证。
## 解决方案
一个中心信任注册表，实体在其中建立经过密码学验证的身份。AI 代理在与任何实体交互之前通过 MCP 查询该注册表。
## 验证级别
| 级别 | 名称 | 方法 |
|-------|------|--------|
| ●○○ L1 | 注册表认证 | 与 21+ 个官方注册表进行交叉验证 |
| ●●○ L2 | 完全验证 | C2PA 签名块 + Bitcoin OpenTimestamps |
| ●●◌ L3 | 实时验证 | 活跃的 PI 摄像头流 · 实时验证 |
## MCP 集成
```yaml
mcp_servers:
- name: teta-pi
url: https://tetapi.dev/mcp
auth: Bearer
```
### MCP 工具
| 工具 | 描述 |
|------|-------------|
| `search_entities` | 按意图和管辖权查询已验证的实体 |
| `get_entity_profile` | 解析具有区块和来源验证的完整已验证个人资料 |
| `verify_endpoint` | 验证代理端点是否属于声明的实体 |
| `get_verification_proof` | 返回 C2PA + Bitcoin 时间戳证明链 |
| `resolve_intent` | 将用户意图路由到正确的已验证实体 |
## 架构
```
实体层 → 个人资料 · 区块 · 隐私切换 · 实体类型
验证层 → C2PA · Bitcoin OpenTimestamps · 端点验证
协议层 → MCP 服务器 · 意图图 · /.well-known/agent.json · 根 CA
```
## 信任架构
TETA+PI 作为根 CA 运行。企业客户收到一个委托的 CA。MIT 许可下的分叉是欢迎的——但没有根 CA，第三方信任无法得到保证。
这与 CA/Browser Forum 的模型相同：开放标准，集中信任锚点。
## 许可证
MIT License 2026 TETA+PI · tetapi.dev
> 验证 = 可见性。在代理互联网中，如果没有验证，实体对代理来说是不存在的。
