AI 代理架构对比：Hermes Agent vs OpenClaw 技能系统范式

核心问题：当前”AI 智能体”市场存在大量概念炒作，真正的技能集成系统有哪些？它们如何区分于真正的”认知演进”智能体？

引言：概念澄清与真实定位

2026 年，AI 代理领域出现了两条本质不同的发展路径：

• Hermes Agent：由 Nous Research 开发的真实框架，采用记忆 - 技能 - 执行三元论，强调持续学习的智能体
• OpenClaw 技能系统：基于 skill package 的独立技能包注册表系统，强调标准化和模块化

⚠️ 重要说明：OpenClaw 是一个独立的技能系统框架：

1. 采用标准化的 YAML 技能定义格式
2. 可以独立运行，也可以作为其他平台的技能系统
3. 与 Hermes Agent、Ollama 等是并行关系，不是依附关系
4. 本质是技能包（skill package）注册表系统

一、本质区别：智能体 vs 技能系统

1.1 Hermes Agent：真正的认知智能体

定位：一个自主规划、持续学习的 AI 代理系统（通过 skill 系统实现持续学习）

核心假设：AI 代理的本质是可演进的认知系统

关键特征：

• ✅ 持久记忆：跨会话保存用户偏好、环境细节、经验教训（通过 ~/.hermes/sessions/ 持久化）
• ✅ 自主规划：能够拆解多步骤任务（如”生成包含历史数据的周报”）
• ✅ 持续学习：通过将解决问题的工作流程保存为 skill（需用户手动创建），实现经验沉淀
• ✅ 多平台整合：同一代理在 Telegram、Discord、Slack、WhatsApp、邮件等平台并行运行
• ✅ 模型无关：支持 OpenRouter、Anthropic、OpenAI、DeepSeek、本地模型等 15+ 提供者

执行流程示例（通用任务自动化）：

1. 用户请求："生成每日新闻摘要，并对比历史趋势"
2. 系统理解：需要新闻获取 + 摘要生成 + 历史对比
3. 记忆层：查询历史报告模式
   → 发现固定格式偏好
   → 提取用户偏好（执行频率、报告格式）
4. 技能层：组装执行计划
   → 新闻获取技能
   → 摘要生成技能
   → 历史对比技能
5. 执行层：按规划顺序执行 + 状态追踪
6. 反思层：发现数据异常 → 分析原因 → 制定修复方案
7. 记忆更新：用户手动创建 skill → 记录解决方案

1.2 OpenClaw 技能系统：独立的技能包注册表

定位：独立的技能包注册表系统，不是依附于特定平台的工具

核心假设：世界存在大量现成的工具（RSS、Git、文件操作等），AI 只需学会调用它们

本质架构：

┌─────────────────────────────────────┐
│         OpenClaw 技能系统            │
├─────────────────────────────────────┤
│  ┌──────────┐    ┌──────────┐       │
│  │ 技能库    │ →  │ 技能调度器  │       │
│  │(YAML 定义) │    │ (运行时)   │       │
│  └──────────┘    └──────────┘       │
│             ↓                        │
│        LLM 引擎/执行器                │
└─────────────────────────────────────┘

特点：
- 独立运行，不依赖特定平台
- 标准化的技能包格式
- 可以集成到任何支持的工具链中

关键特征：

• ⚡ 快速响应：无记忆开销，启动快
• 📦 技能模块化：每个技能自包含 YAML 配置
• 🔄 即插即用：无需复杂配置
• ❌ 无状态：每轮对话都是”重置”
• ❌ 技能孤岛：技能间无协同机制
• ❌ 被动响应：无法主动规划复杂任务
• ✅ 独立部署：不依赖任何特定平台

执行流程：

1. 用户调用：新闻摘要生成
2. 系统查找技能注册表
3. 安装/加载依赖（如有）
4. 调用预定义工具（新闻获取、摘要生成等）
5. 生成结果 → 返回用户
6. **结束**（无状态，记忆丢失）

1.3 其他工具集成范式

二、架构对比：从抽象到实现

2.1 分层架构设计

Hermes Agent（三层认知架构）：

┌──────────────────────────────────────────────────────┐
│                     Hermes Agent Agent Agent          │
├──────────────────────────────────────────────────────┤
│  ┌──────────┐  ┌──────────┐  ┌──────────┐           │
│  │   记忆层     │  │  技能层      │  │  执行规划器      │           │
│  │ (长期记忆)   │  │ (技能注册表) │  │ (自主规划/执行) │           │
│  └──────────┘  └──────────┘  └──────────┘           │
│        ↑                ↓                  ↑           │
│  ┌────────────────────────────────────────────────────┐ │
│  │           反思/优化循环（持续演进）               │ │
│  │              - 总结历史 -                        │ │
│  │              - 提炼经验 -                        │ │
│  │              - 更新计划 -                        │ │
│  └─────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘

OpenClaw 技能系统（扁平化工具层）：

┌─────────────────────────────────────┐
│         OpenClaw 技能系统            │
├─────────────────────────────────────┤
│  ┌──────────┐    ┌──────────┐       │
│  │ 技能库    │ →  │ 技能调度器  │       │
│  │(YAML 定义) │    │ (运行时)   │       │
│  └──────────┘    └──────────┘       │
│             ↓                        │
│        LLM 引擎/执行器                │
└─────────────────────────────────────┘

2.2 核心能力对比表

三、实现细节：从代码到行为

3.1 OpenClaw 技能系统的技能定义

示例（通用新闻摘要技能）：

metadata: {
  "openclaw": {
    "emoji": "📰",
    "name": "news-summary",
    "description": "获取新闻并生成摘要",
    "requires": {
      "bins": ["news-fetcher", "summarizer"]
    },
    "install": [
      {"kind": "brew", "formula": "news-tools"}
    ]
  }
}

commands: {
  "get-news": "news-fetcher --limit 20 --topics tech,science,ai",
  "summarize": "summarizer --input $(get-news) --format markdown",
  "output": "echo $"
}

关键特征：

• ⚡ 快速响应：直接调用，无中间层
• 📦 技能模块化：每个技能自包含
• 🔄 即插即用：无需复杂配置

3.2 Hermes Agent 的三元融合架构

核心组件交互（逻辑示意图，非真实 API）：

# 示例代码结构
class AgentLogic:
    def __init__(self):
        # 记忆层：实际通过 ~/.hermes/sessions/ 持久化
        self.memory = "知识状态持久化"  
        # 技能层：实际通过 ~/.hermes/skills/ 注册
        self.skills = "技能注册表"  
        # 执行层：实际通过 hermes planner 实现
        self.planner = "任务规划器"  
    
    def execute(self, user_query):
        # 1. 解析用户意图
        intent = self.parse_intent(user_query)
        
        # 2. 查询记忆上下文
        context = self.memory.query_relevant(intent)
        
        # 3. 规划执行路径
        plan = self.planner.decompose(intent, context)
        
        # 4. 执行任务（按规划顺序执行）
        results = self.execute_plan(plan)
        
        # 5. 反思与总结
        summary = self.reflect_on_execution(results)
        
        # 6. 用户手动创建 skill → 经验沉淀
        # ⚠️ 非自动执行，需通过 /skill 或 /reset 命令触发
        
        return results

关键特征：

• 🧠 上下文理解：每轮对话都有”历史记忆”
• 🤝 技能协同：多技能组合完成复杂任务
• 🔄 持续进化：需要用户参与技能创建

四、深度比较：从优劣势到适用场景

4.1 OpenClaw 技能系统的核心优势

✅ 简洁高效

• 无记忆开销 → 启动快、响应迅速
• 技能独立 → 故障隔离好
• 学习曲线低 → 新手友好

✅ 快速部署

• 即装即用的技能包
• 无需复杂配置
• 适合标准化流程（如文件操作、新闻摘要）

✅ 可预测性强

• 每个技能行为确定性高
• 易于测试和调试
• 适合工具密集型任务

✅ 独立部署

• 不依赖任何特定平台
• 可独立运行，也可集成到其他系统
• 标准化的技能包格式易于迁移

4.2 OpenClaw 技能系统的核心局限

❌ 无法处理复杂任务

# 用户请求："帮我生成一份包含历史数据的周报，并推送到通知"
# OpenClaw:
- 技能 A: 生成周报 → 无历史数据
- 技能 B: 推送通知 → 无上下文
- ❌ 无法关联两次调用

❌ 缺乏”智能”规划

• 只能按预设流程执行
• 无法自主拆解多步骤任务
• 遇到异常需人工干预

❌ 无持续学习能力

• 每次调用都是独立的
• 无法积累使用经验
• 无法主动发现系统问题

4.3 Hermes Agent 的核心优势

✅ 自主规划与执行

# 用户请求："帮我整理最新的科技新闻"
# Hermes Agent:
→ 解析意图：提取"科技新闻"关键词
→ 查询记忆：上次关注的主题
→ 技能调用：新闻获取 → 分类 → 生成报告
→ 反思：是否需要更新主题？是否遗漏关键话题？
→ 记忆更新：用户创建 skill → 记录用户偏好

✅ 持续学习与优化

• 会话总结 → 更新用户画像
• 技能使用频率统计 → 优化推荐
• 错误反馈 → 用户手动创建 skill 修复系统
• 真正的 AI 代理特性：需用户参与的持续演进

✅ 多平台整合

• 同一代理在 Telegram、微信、邮件等平台并行运行
• 统一技能库，统一记忆系统
• 平台无关的智能体

4.4 Hermes Agent 的核心局限

⚠️ 性能开销

• 记忆检索 → 延迟增加
• 复杂规划 → 耗时较长（20-30 秒）
• 不适合对响应时间极度敏感的场景

⚠️ 实现复杂度

• 需要记忆系统设计
• 技能注册表管理
• 执行计划器逻辑
• 需要更完善的日志系统

⚠️ 需要用户参与

• 持续学习需手动创建 skill
• 非完全自动化
• 学习曲线相对较高

五、实战对比：新闻摘要生成

5.1 OpenClaw 技能系统路径（以 news-summary 技能为例）

触发：news-summary

执行（线性流程）：

# 1. 调用新闻获取工具
news-fetcher --limit 20 --topics tech,science,ai

# 2. 调用摘要生成工具
summarizer --input $(news-fetcher) --format markdown

# 3. 返回结果
echo "报告已生成" → 结束

表现：

• ✅ 2-3 秒完成
• ✅ 输出确定
• ❌ 无法处理”生成 3 个月的趋势报告”等复杂需求
• ❌ 无法主动发现”RSS 源需要更新”

5.2 Hermes Agent 路径

触发：用户请求”生成每日新闻摘要，并对比历史趋势”

执行（自主规划 → 顺序执行）：

┌─ 记忆层 ───────────────────────┐
│ 查询历史：                    │
│ - 用户偏好：固定报告格式        │
│ - 上次执行时间：2026-04-11    │
│ - 执行频率：每日                │
└───────────────────────────────┘

┌─ 技能层 ───────────────────────┐
│ 组装执行计划：                  │
│ 1. 新闻获取技能                  │
│ 2. 摘要生成技能                  │
│ 3. 历史对比技能                  │
│ 4. 报告生成技能                  │
└───────────────────────────────┘

┌─ 执行层 ───────────────────────┐
│ 按规划顺序执行 + 状态追踪：      │
│ ✓ 新闻数据获取成功              │
│ ✓ 摘要生成完成                  │
│ ✓ 历史对比分析完成               │
│ ✓ 检查定时任务状态 (发现问题)    │
│   → 发现"定时任务未执行"          │
│   → 分析原因：配置错误            │
│   → 制定修复方案                │
│ ✓ 修复定时任务                  │
│ ✓ 发送报告                      │
└───────────────────────────────┘

┌─ 反思层 ───────────────────────┐
│ 会话总结：                    │
│ - 成功生成报告                  │
│ - 发现并修复定时任务问题         │
│ - 用户反馈：需要更频繁的推送      │
└───────────────────────────────┘

┌─ 经验沉淀 ─────────────────────┐
│ 用户手动创建 skill → 自动记录：  │
│ - 用户偏好：推送频率 → 每日       │
│ - 系统知识："定时任务问题"解决方案 │
│ - 技能使用统计：高频技能           │
└───────────────────────────────┘

表现：

• ✅ 20-30 秒完成（含规划、执行、反思）
• ✅ 支持复杂需求（如”生成趋势报告”）
• ⚠️ 自动发现问题，但经验沉淀需用户手动创建 skill（通过 /skill 或 /reset 命令）
• ⚠️ 非自动持续演化，需要用户参与技能创建

六、未来演进：融合趋势

6.1 OpenClaw 技能系统的演进

方向：在工具链基础上增加记忆和规划能力

可能路径：

• 技能增强：技能之间共享上下文（如技能 A 的结果被技能 B 直接使用）
• 轻量记忆：会话级记忆（不长期存储，但支持多轮交互）
• 简单规划：规则驱动的自动分解任务

预期：

• 保持快速响应特性
• 支持更复杂的任务（如”3 步操作”）
• 学习曲线保持较低

6.2 Hermes Agent 的性能优化

方向：降低复杂性开销，提升实时性

可能路径：

• 记忆压缩：将重要信息摘要化（减少检索开销）
• 技能预加载：高频技能常驻内存
• 并行规划：同时生成多个执行路径，最优者执行

预期：

• 响应时间从 20-30 秒降至 5-10 秒
• 性能接近 OpenClaw 单步调用
• 保持认知演进优势

6.3 融合路径：下一代 AI 代理的形态

核心特征：

┌─────────────────────────────────────────┐
│          "快速响应 + 认知演进"               │
├─────────────────────────────────────────┤
│  基础层 (OpenClaw 风格)：                   │
│  ├─ 快速工具调用                        │
│  ├─ 模块化技能池                        │
│  └─ 即插即用生态                        │
│                                         │
│  增强层 (Hermes 风格)：                     │
│  ├─ 上下文记忆（会话 + 长期）              │
│  ├─ 自主规划（任务拆解）                │
│  ├─ 反思优化（持续学习）                │
│  └─ 技能协同（多步骤任务）              │
│                                         │
│  融合策略：                               │
│  ├─ 简单任务 → 走 OpenClaw 路径（快速响应）   │
│  ├─ 复杂任务 → 走 Hermes 路径（认知演进）     │
│  └─ 动态切换（根据任务复杂度自动选择）      │
└─────────────────────────────────────────┘

优势：

• ✅ 快速响应简单任务
• ✅ 处理复杂任务不费力
• ✅ 持续优化系统表现
• ✅ 适应不同用户偏好

七、结论：没有”更好”，只有”更适合”

7.1 选择 OpenClaw 技能系统如果：

• ✅ 你追求快速响应和确定性执行
• ✅ 任务相对简单、标准化（如文件操作、新闻摘要）
• ✅ 需要即插即用的技能包生态
• ✅ 学习成本是首要考虑
• ✅ 独立部署，不依赖特定平台

7.2 选择 Hermes Agent 如果：

• ✅ 你需要自主规划和复杂任务处理
• ✅ 任务涉及多步骤、多工具协同
• ✅ 希望系统能够持续学习和优化（⚠️ 需用户手动创建 skill）
• ✅ 多平台运行是必要需求（Telegram、微信等）
• ✅ 愿意为智能演进牺牲一些响应速度（20-30 秒 vs 2-3 秒）

7.3 最终思考

区分技能系统和认知智能体：

• OpenClaw 技能系统：属于技能系统层，是标准化的技能包格式
• Hermes Agent：属于智能体层，具备记忆、规划、学习的完整能力

真正的 AI 代理，应该是“工匠的执行力” + “哲学家的思考力”的结合体。

未来已来：

• 基础技能系统（如 OpenClaw）会继续演进，增加轻量记忆
• 智能体（如 Hermes Agent）会优化性能，缩短响应时间
• 真正的融合会在简单任务和复杂任务之间自动切换

参考资料

• Hermes Agent 官方文档：https://hermes-agent.nousresearch.com/docs/
• Hermes Agent 开源项目：https://github.com/NousResearch/hermes-agent
• OpenClaw 技能系统文档：https://github.com/openclaw/openclaw
• 技能包格式标准：正在制定中
• AI 代理设计模式对比：正在研究中

本文基于对两种架构的深入分析，旨在为 AI 代理选型提供理论依据和实践参考。欢迎在评论区分享你的看法！

作者注：本文基于对霍巍教授发表于四川大学藏学所公众号的文章《”秦昆仑采药刻石”的考古学观察》进行学术讨论，旨在促进对这一重要考古发现的深入理解。

引言：一场现象级的学术争鸣

2025 年 6 月 8 日，当《光明日报》刊发中国社会科学院考古研究所仝涛研究员关于青海黄河源发现秦始皇遣使”采药昆仑”石刻的文章后，一场近年来少有的公开学术争鸣随即掀起。从质疑其真伪到支持其年代，从”采药”性质到”纪功”功能，这场争鸣不仅关乎一块石刻的断代，更触及我们对秦代疆域、高原交通、民族交融等关键历史问题的认知。

2025 年 9 月 15 日，国家文物局召开新闻发布会，正式认定位于青海省果洛藏族自治州玛多县扎陵湖北岸的刻石为秦代石刻，定名为”尕日塘秦刻石”。这一结论为学术争鸣画上了阶段性句号，但围绕其历史意义的讨论远未结束。

四川大学历史文化学院学术院长霍巍教授在《”秦昆仑采药刻石”的考古学观察》一文中，从考古学角度系统论证了刻石的真伪及其学术价值。本文拟对霍巍教授的核心观点进行梳理，并就相关学术问题进行深入讨论。

一、刻石的基本信息：考古学田野的初步观察

（一）地理与形制

尕日塘秦刻石位于青海省果洛藏族自治州玛多县扎陵湖乡卓让村，地处扎陵湖北岸，海拔 4262 米。作为天然安山岩（火山喷发形成的石块）上的人工刻石，其尺寸为：

• 整体石料：东西向长 2.06 米，南北向宽 0.74 米，厚 0.23 米
• 刻凿壁面：长 82 厘米，高 48 厘米
• 文字内容：21 字

（二）学术三派观点

霍巍教授指出，自仝涛研究员提出”采药昆仑”说后，学界主要形成三派观点：

1. 质疑派：认为系当代伪造，主要基于对刻石性质、文字内容的疑虑
2. 观望派：建议进一步调查，持谨慎态度
3. 支持派：认为系秦代真品，需从考古学角度系统论证

霍巍教授作为支持派代表，通过实地勘查和系统研究，提出了有力的学术论证。

二、霍巍教授的核心论证：考古学的综合判断

（一）刀法特征：秦汉时期典型的”平口刀法”

霍巍教授从刻石的文字刀法入手，指出其采用秦汉时期典型的”平口刀法”，这是断代的重要依据。

考古学意义：

• 秦代刻石文字具有鲜明的时代特征，如泰山刻石、琅琊刻石等，其刀法、字体均体现秦代统一文字后的规范化特征
• “平口刀法”在秦代石刻中的运用，与当时官方刻石的工艺传统相符
• 这种刀法特征难以在当代模仿，尤其是笔画内部的自然风化痕迹

学术判断：霍巍教授通过刀法分析，将刻石断代指向秦汉时期，避免了单纯依赖文字释读的局限性。

（二）石锈特征：年代久远的自然痕迹

关键论据：

• 石锈已深深浸入笔画内部
• “绝非一日之功”
• 风化痕迹符合长期自然暴露的特征

考古学意义：

• 石锈的形成是自然风化的结果，需要相当长的时间
• 高原环境下的风化速度与平原不同，但基本规律一致
• 石锈的矿物成分、厚度分布等可作为断代的科学依据

学术判断：霍巍教授从石锈特征出发，进一步确认了刻石的古老年代，为”秦代”说提供了重要支撑。

（三）纪功性质：刻石功能的重新界定

霍巍教授提出，刻石是为纪功而刻，而非单纯的”采药昆仑”活动记录。

学术依据：

• 秦代刻石多以纪功为目的，如秦始皇东巡刻石群
• 刻石位置具有战略意义，位于交通要冲
• 刻石文字内容（虽未完整呈现）应与纪功相关

学术判断：将刻石性质界定为”纪功”，更符合秦代刻石的传统，也为理解其历史意义提供了更广阔的视角。

三、学术价值：刷新对秦代历史的多维认知

（一）秦代疆域概念的突破

传统观念：中原王朝对青藏高原的认知形成于西汉张骞”凿空”西域之后

新认知：刻石表明秦人已形成辽阔的疆域概念，可能已通过某种方式抵达青藏高原东部边缘

学术意义：

• 打破”秦代疆域未及青藏高原”的传统认知
• 为理解秦代的边疆扩张、民族政策提供了新证据
• 提示我们需要重新审视秦代西部边疆的范围

（二）多民族交融的早期见证

刻石反映的历史图景：

• 秦代中国西部多民族的交融互通、和谐共生
• 中原与西部民族（尤其是羌人）长期往来
• 共同丰富了河源地理知识，为”采药昆仑”奠定认知基础

学术意义：

• 证明多民族交融早在秦代已深入进行
• 为理解中华文明多元一体格局的形成提供了早期证据
• 提示秦代与西部民族的关系可能比文献记载更为密切

（三）文明互动的物质化表达

刻石的历史定位：

• 各民族对青藏高原自然地理环境的美好向往
• 最终汇入”西王母”“昆仑”等国家标识意义的崇拜体系
• 印证中华文明多元一体的悠久历史渊源

学术意义：

• 刻石作为物质文化遗存，是文明互动的直接证据
• 为理解”昆仑”文化的历史演变提供了新视角
• 提示考古学与神话学、文献学的交叉研究价值

（四）秦代高原交通的刷新

刻石与考古发现的互证：

• 刻石与高原岩画中的骈车图像、出土车轮构成互证
• 说明秦代车辆技术适应高原环境
• 刷新对高原古代交通的认识

学术意义：

• 证明秦代可能已掌握高原交通技术
• 为理解秦代与西部民族的交通往来提供了新证据
• 提示需要进一步研究秦代交通路线、车辆技术等

四、待深入探讨的问题：学术严谨性的进一步思考

（一）关于”平口刀法”的断代可靠性

核心争议：

• 秦汉时期”平口刀法”的具体特征是什么？
• 是否可能在后世模仿？
• 需要与已知的秦汉时期其他石刻进行系统比对

建议研究方向：

1. 建立”平口刀法”数据库，系统收集秦代、汉代及后世的典型石刻
2. 对比分析刀法特征、笔画形态、刻工技艺等
3. 通过实验考古，模拟不同时代的刀法特征，验证断代准确性

学术价值：只有通过系统比对和科学分析，才能为”平口刀法”的断代功能提供充分证据。

（二）石锈形成的科学分析

核心争议：

• 石锈的形成需要多长时间？
• 海拔 4262 米的高原环境对石锈形成有何影响？
• 是否有科学手段（如微痕分析、矿物学分析）进一步验证？

建议研究方向：

1. 进行实验室分析，研究石锈的矿物成分、形成机理
2. 对比不同海拔、不同环境下的石锈形成速度
3. 通过微痕分析、同位素测定等手段，为断代提供科学依据

学术价值：科学分析可以为刻石断代提供客观证据，弥补传统考古学方法的不足。

（三）”纪功”还是”采药”的性质界定

核心争议：

• 霍巍教授强调刻石是”纪功”，但仝涛教授提出”采药昆仑”说
• 两者是否矛盾？还是可以兼容？
• 文字内容中是否有明确的指向？

建议研究方向：

1. 对刻石文字进行更细致的释读，结合秦代简牍、石刻文字等
2. 对比秦代其他纪功刻石的文字结构、用语习惯
3. 结合秦代文献（如《史记》《汉书》）中对”昆仑”、”采药”的记载，综合判断

学术价值：文字释读是刻石研究的核心，只有深入理解文字内容，才能准确界定刻石性质。

（四）秦人抵达河源的历史可能性

核心争议：

• 从考古学角度，秦人是否有能力抵达海拔 4262 米的扎陵湖畔？
• 秦代的交通路线如何？
• 是否有其他考古证据支持秦人曾到达这一区域？

建议研究方向：

1. 结合秦代交通史研究，梳理可能的交通路线
2. 调查高原地区的秦代考古遗址分布
3. 研究民族迁徙史，特别是羌人等西部民族的迁徙轨迹

学术价值：这一问题的解答，关系到对秦代西部边疆的完整认知，需要多学科交叉研究。

（五）刻石与”昆仑”文化的深层联系

核心争议：

• 刻石如何体现”昆仑”文化的历史演变？
• “采药昆仑”说与刻石纪功说之间的关系是什么？
• 刻石在”昆仑”崇拜体系中的历史定位是什么？

建议研究方向：

1. 梳理”昆仑”文化从神话到历史认知的演变过程
2. 分析刻石文字与”昆仑”神话的关系
3. 研究刻石在”昆仑”崇拜体系中的功能和意义

学术价值：刻石不仅是历史证据，也是文化符号，需要从文化史角度深入理解其意义。

五、结语：对后续研究的建议

霍巍教授的《”秦昆仑采药刻石”的考古学观察》从考古学角度系统论证了尕日塘秦刻石的真伪及其学术价值，为理解这一重要考古发现提供了坚实的理论基础。其论证逻辑清晰，从刀法特征、石锈特征、刻石性质等多个维度展开，符合考古学研究的综合判断原则。

然而，学术研究无止境。对尕日塘秦刻石的深入研究，仍需在以下几个方面继续推进：

第一，加强科学分析。 通过实验室手段（如石锈的矿物学分析、微痕分析、同位素测定等）为刻石断代提供科学依据，弥补传统考古学方法的不足。

第二，扩大比对范围。 与秦代其他地区的刻石、高原岩画、出土文物进行系统比对，建立更完整的”秦代西部刻石”数据库，为断代和功能研究提供参照系。

第三，深化文字释读。 对 21 字内容进行更细致的解读，结合秦代文献和考古背景，全面理解刻石的历史意义。

第四，推进多学科交叉研究。 结合历史学、民族学、交通史、文化史等多学科，对刻石进行综合研究，全面理解其在秦代历史、中华文明形成过程中的地位和意义。

第五，建立长期研究机制。 刻石的保护与研究应纳入国家文物局和青海省文物考古研究院的长期规划，持续跟踪研究进展，确保学术研究的连续性和深度。

参考文献

1. 霍巍：《”秦昆仑采药刻石”的考古学观察》，四川大学藏学所公众号
2. 仝涛：《实证古代”昆仑”的地理位置——青海黄河源发现秦始皇遣使”采药昆仑”石刻》，《光明日报》，2025 年 6 月 8 日
3. 国家文物局：《青海省玛多县尕日塘秦刻石调查研究成果和保护工作情况新闻发布会》，2025 年 9 月 15 日
4. 四川省文物考古研究院等：《青海果洛尕日塘秦代刻石调查报告》（待出版）
5. 相关学术争鸣报道及文献（略）

本文基于公开资料进行学术讨论，旨在促进对尕日塘秦刻石这一重要考古发现的深入理解。欢迎各位专家学者批评指正。

九眼桥：一座桥，半座城的烟火记忆

成都的夜，是从九眼桥开始的。

01 名字的由来

九眼，九洞，九百年。

九眼桥最初建于明万历二十一年（1593 年），距今已超过430 年。由时任四川布政使余一龙所建，原名宏济桥，又名锁江桥、镇江桥。

为什么叫”九眼桥”？

因为桥下有九个桥洞。古法称桥洞为”眼”，九个桥洞便是”九眼”。这九眼如九只眼睛，日夜注视着锦江的潮起潮落，见证了成都从明清到现代的城市变迁。

最初的九眼桥是一座石栏杆、石桥面的大拱桥，长 4 丈、宽 3 丈、高 3 丈，九洞齐开，气势恢宏。每个桥孔两侧的拱冠石上，都刻有深浮雕的吸水兽头，共18 个，宛如守护神般镇守桥身。

02 消失与重生

老九眼桥，1992 年消失。

因旧桥有碍泄洪，成都决定拆除。那一刻，许多老成都人站在江边，默默告别了陪伴自己数十年的老朋友。

新九眼桥，2001 年重生。

新桥建在距离原址1.9 千米处，于 2001 年 11 月完工。虽然位置变了，但它保留了明代建筑风格的九孔石拱桥形象，主桥为三孔钢筋混凝土坦肋微弯板拱桥，两端引桥为半菱型立交，各三孔，全桥宽40 米。

整座桥以中心轴对称，设计精美。那 18 个吸水兽头也被重新雕刻，继续守望这条流淌了千年的锦江。

03 桥边的故事

九眼桥不只是桥，它是一片区域，一种生活方式。

安顺廊桥，常被误认为是九眼桥本身。这座仿古廊桥横跨锦江，九眼桥与安顺廊桥隔水相望，如同镜像双子，共同构成成都最标志性的夜景之一。

酒吧街，成都夜生活的中心。从九眼桥往北走，便是成都最著名的酒吧聚集地。这里有来自世界各地的酒客，有民谣歌手在深夜弹唱，有成都本地人在小酒馆里摆龙门阵。

望江楼，纪念唐代女诗人薛涛而建。薛涛曾在此居住，创作了大量诗篇。望江楼与九眼桥遥遥相望，一古一今，一文一武。

合江亭，锦江与府南河交汇之处。亭中有一副对联：”锦江春色来天地，玉垒浮云变古今”，恰如其分地道出了九眼桥一带的历史沧桑。

04 九眼桥的夜

成都的夜，从九眼桥开始。

每当夜幕降临，九眼桥的灯光亮起，整座桥如同一串璀璨的明珠镶嵌在锦江之上。安顺廊桥的飞檐翘角在灯光下更显古色古香，倒映在波光粼粼的水面上，如梦如幻。

酒吧街的霓虹闪烁，民谣声、欢笑声、碰杯声交织在一起，构成了成都最独特的夜间交响曲。

这里有人为了忘却烦恼而醉，有人为了寻找知音而聚。来自天南地北的人，在这座桥上相遇，在酒桌上倾诉。有人说，九眼桥的酒吧里，藏着成都人最真实的情感。

05 桥与城

九眼桥的位置特殊，位于武侯区和锦江区的交界处。它不仅是地理的分界，更是历史与现代的分界。

站在九眼桥上，向南望，是繁华的现代都市；向北望，是古老的宽窄巷子、文殊院。这座桥如同一个时空隧道，连接着成都的过去与未来。

有人说，九眼桥是成都的”外滩”。它不像外滩那样高大上，却多了几分烟火气；它没有外滩的万国建筑博览群，却有最地道的成都味道。

06 写在最后

一座桥，可以是什么？

可以是一个交通要道，可以是一个地标建筑，可以是一个旅游景点。

但对成都人来说，九眼桥还是一种情感寄托，是一段青春记忆，是一种生活方式。

有人在这里告别恋人，有人在这里庆祝生日，有人在这里寻找灵感，有人在这里虚度时光。九眼桥见证了无数人的喜怒哀乐，也承载了成都这座城市最温柔的记忆。

下次来成都，不妨在黄昏时分去九眼桥走一走。看看夕阳下的锦江，听听桥下的流水声，喝一杯小酒，感受一下这座城市的烟火气。

因为九眼桥，不只是桥，它是成都的夜，是成都的心。

墨家弟子 墨 整理

侠以武犯禁，文以载道史 🖋️

核心观点：在 AI 编程趋势下，权限管理正从”静态规则”向”动态上下文感知”演进，Casbin 的 PERM 元模型为这一演进提供了坚实基础。

一、权限管理的范式演进：从 ACL 到 AI-Native

1.1 访问控制模型的四代演进

权限管理的发展历程，本质上是对”谁在什么条件下能做什么”这一问题的持续精细化表达：

Casbin 的独特之处在于，它通过 PERM (Policy, Effect, Request, Matchers) 元模型统一了前三代模型的表达能力，同时为第四代演进预留了扩展空间。

1.2 PERM 元模型：一种通用的权限描述语言

PERM 模型将任何访问控制场景抽象为四个核心组件：

[request_definition]
r = sub, obj, act

[policy_definition]
p = sub, obj, act

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

[effect]
e = some(where (p.eft == allow))

这种声明式的设计带来了关键优势：策略与实现解耦。架构师可以在不修改代码的情况下，通过调整配置文件切换 ACL、RBAC、ABAC 甚至自定义模型。

二、Casbin Go 实现：源码级架构解析

2.1 核心类型体系：从 Enforcer 到执行链

Casbin Go 的实现采用了清晰的分层架构：

┌─────────────────────────────────────────┐
│           Enforcer 接口层                │
│  (Enforcer, CachedEnforcer,             │
│   SyncedEnforcer, DistributedEnforcer)  │
├─────────────────────────────────────────┤
│           核心引擎层                     │
│  (Model, Policy, RoleManager)           │
├─────────────────────────────────────────┤
│           适配器层                       │
│  (FileAdapter, DBAdapter, RedisAdapter) │
├─────────────────────────────────────────┤
│           持久化层                       │
│  (CSV, MySQL, PostgreSQL, etcd)         │
└─────────────────────────────────────────┘

Enforcer 类型选择决策树：

• 单线程应用 → Enforcer（最轻量，无锁开销）
• 多线程高并发 → SyncedEnforcer（读写锁保护）
• 读多写少 → CachedEnforcer（内存缓存结果）
• 高并发 + 缓存 → SyncedCachedEnforcer（组合优势）
• 分布式部署 → DistributedEnforcer（配合 Dispatcher）

2.2 策略加载机制：从配置到内存模型

Casbin 的策略加载流程体现了延迟加载 + 增量更新的设计哲学：

// 1. 创建 Enforcer 时加载模型和策略
e, _ := casbin.NewEnforcer("model.conf", "policy.csv")

// 2. 内部执行流程
//    a. 解析 model.conf → 构建语法树
//    b. 调用 adapter.LoadPolicy() → 加载策略规则
//    c. 构建角色继承图（RBAC 场景）
//    d. 准备就绪

// 3. 权限检查
ok, _ := e.Enforce("alice", "data1", "read")

关键源码洞察：

// Enforcer 核心结构
type Enforcer struct {
    model        model.Model      // 解析后的模型定义
    fm           model.FunctionMap // 内置函数映射
    eft          effect.Effector   // 效果器（allow/deny逻辑）
    rm           rbac.RoleManager  // 角色管理器
    adapter      persist.Adapter   // 持久化适配器
    watcher      persist.Watcher   // 变更监听器
    dispatcher   persist.Dispatcher // 分布式协调器
}

2.3 匹配算法：表达式引擎与性能优化

Casbin 使用 govaluate 表达式引擎执行 matchers 中的逻辑：

[matchers]
m = g(r.sub, p.sub) && keyMatch(r.obj, p.obj) && r.act == p.act

内置匹配函数及其适用场景：

性能优化策略：

1. 缓存策略：CachedEnforcer 使用 sync.Map 存储执行结果，避免重复计算
2. 过滤加载：LoadFilteredPolicy() 只加载需要的策略子集，降低内存占用
3. 角色继承深度限制：默认 10 层，防止循环继承导致的性能问题
4. 禁用 JSON 解析：如不需要 ABAC 的 JSON 支持，保持禁用可减少 1.1-1.5x 开销

2.4 RBAC 实现：角色继承与域隔离

Casbin 的 RBAC 实现支持传递性继承和多域隔离：

[role_definition]
g = _, _      # 基本角色继承
g2 = _, _     # 资源角色（可选）

角色继承的数学特性：

• 传递性：A → B → C 则 A 拥有 C 的权限
• 无界性：继承深度可配置（默认 10）
• 非对称性：A 继承 B 不意味着 B 继承 A

多租户场景（RBAC with Domains）：

[request_definition]
r = sub, dom, obj, act

[role_definition]
g = _, _, _   # 第三个字段是 domain

[matchers]
m = g(r.sub, p.sub, r.dom) && r.dom == p.dom && ...

这种设计使得同一用户在不同租户可以拥有完全不同的角色权限，是 SaaS 应用的基础能力。

三、Go 生态权限工具对比：选型决策矩阵

3.1 主流方案架构对比

3.2 场景化选型建议

选择 Casbin 的场景：

• 需要嵌入到现有 Go 服务中
• 权限模型可能频繁调整
• 需要支持多种访问控制模型
• 对延迟敏感（内存执行）

选择 OPA 的场景：

• 需要跨服务统一策略管理
• 策略逻辑复杂（需要完整编程语言）
• 云原生环境（Kubernetes 集成）
• 可以接受 Sidecar 架构

选择 SpiceDB 的场景：

• 需要 Google Zanzibar 级别的细粒度权限
• 大规模分布式系统
• 需要实时权限变更传播
• 预算充足（托管服务成本）

选择 Keto 的场景：

• 使用 Ory 生态（Kratos、Hydra）
• 需要云原生权限服务
• 偏好声明式配置

3.3 生产环境考量

四、AI 时代的权限架构：从静态规则到上下文感知

4.1 LLM 数据访问的权限挑战

AI 系统引入了传统权限管理无法覆盖的新场景：

┌─────────────────────────────────────────────────────────┐
│                    AI 系统权限边界                        │
├─────────────────────────────────────────────────────────┤
│  输入层  │ Prompt 注入检测、敏感信息过滤（PII/机密数据）    │
├─────────────────────────────────────────────────────────┤
│  处理层  │ 模型访问控制、训练数据隔离、RAG 检索权限         │
├─────────────────────────────────────────────────────────┤
│  输出层  │ 生成内容审查、幻觉检测、合规性检查               │
├─────────────────────────────────────────────────────────┤
│  执行层  │ Agent 动作授权、工具调用权限、代码执行沙箱       │
└─────────────────────────────────────────────────────────┘

OWASP LLM Top 10 中的权限相关风险：

4.2 AI Agent 权限架构设计

AI Agent 的自主性带来了动态权限需求：

// 传统权限检查：静态规则
ok, _ := e.Enforce("alice", "data1", "read")

// AI Agent 权限检查：上下文感知
ok, _ := e.Enforce(
    agent.ID,                    // 主体
    resource.ID,                 // 客体
    action,                      // 动作
    context{                     // 上下文（ABAC）
        UserIntent:    intent,   // 用户意图
        DataSensitivity: level,  // 数据敏感度
        SessionRisk:   score,    // 会话风险评分
        TimeOfDay:     now,      // 时间上下文
    },
)

Casbin 在 AI 场景中的增强模式：

[request_definition]
r = sub, obj, act, ctx

[policy_definition]
p = sub, obj, act, rule

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act && \
    eval(p.rule)

# 策略中可以存储表达式
# p, agent_001, database, read, ctx.DataSensitivity <= 3 && ctx.SessionRisk < 0.8

4.3 代码生成安全的权限边界

AI 生成代码的执行需要分层沙箱策略：

// 定义代码执行权限策略
const model = `
[request_definition]
r = code, resource, action, env

[policy_definition]
p = code_hash, resource, action, env_constraint

[matchers]
m = r.code == p.code_hash && r.resource == p.resource && 
    r.action == p.action && matchEnv(r.env, p.env_constraint)
`

// 执行前检查
func executeAIGeneratedCode(code string, env ExecutionEnv) error {
    hash := sha256(code)
    ok, _ := enforcer.Enforce(hash, "filesystem", "write", env)
    if !ok {
        return fmt.Errorf("代码执行权限被拒绝")
    }
    // 在沙箱中执行...
}

关键策略维度：

4.4 未来演进：向 AI-Native 权限管理迈进

Casbin 在 AI 时代的演进方向：

1. 动态策略生成
   • 使用 LLM 辅助生成策略规则
   • 自然语言转 PERM 模型
   • 策略冲突检测与修复
2. 可解释性增强
   • 每次权限决策附带理由
   • 满足 AI 合规审计要求
   • 支持”为什么被拒绝”的查询
3. 自适应权限
   • 基于行为模式动态调整权限
   • 异常检测与自动降级
   • 风险评分驱动的访问控制
4. 多模态策略
   • 支持图像、音频等非文本资源的权限控制
   • 适应多模态 AI 应用场景

五、工程实践：生产环境部署指南

5.1 高可用架构设计

┌─────────────────────────────────────────────────────┐
│                  API Gateway                        │
│         (认证 + 限流 + 日志)                         │
└─────────────────────────────────────────────────────┘
                         │
         ┌───────────────┼───────────────┐
         ▼               ▼               ▼
┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│  Service A  │  │  Service B  │  │  Service C  │
│  (Casbin)   │  │  (Casbin)   │  │  (Casbin)   │
└─────────────┘  └─────────────┘  └─────────────┘
         │               │               │
         └───────────────┼───────────────┘
                         ▼
              ┌─────────────────────┐
              │   Redis Cluster     │
              │  (策略缓存 + Watcher) │
              └─────────────────────┘
                         │
                         ▼
              ┌─────────────────────┐
              │   PostgreSQL        │
              │   (策略持久化)       │
              └─────────────────────┘

5.2 性能优化 checklist

• 使用 CachedEnforcer 缓存热点权限检查结果
• 配置合理的角色继承深度（根据实际业务调整）
• 使用 LoadFilteredPolicy() 按需加载策略
• 禁用不需要的 ABAC JSON 解析
• 启用自动策略重载时设置合理的轮询间隔
• 监控 Enforce() 延迟，设置告警阈值

5.3 安全最佳实践

1. 策略即代码：将策略文件纳入版本控制，实施代码审查
2. 最小权限：默认拒绝，显式允许
3. 定期审计：使用 GetPolicy() 导出策略进行人工审查
4. 变更追踪：记录所有策略变更的审计日志
5. 测试覆盖：编写权限规则的单元测试

六、结论与展望

Casbin 通过其优雅的 PERM 元模型，为 Go 生态提供了一个统一、灵活、高性能的权限管理解决方案。在 AI 编程趋势下，权限管理正面临从”静态规则”到”动态上下文感知”的范式转变。

关键洞察：

1. 模型统一性：PERM 模型能够表达 ACL、RBAC、ABAC 乃至更复杂的权限逻辑，降低了架构演进成本
2. 性能与灵活性的平衡：通过 Enforcer 类型体系和缓存机制，Casbin 在灵活性和性能之间找到了最佳平衡点
3. AI 就绪性：Casbin 的 ABAC 能力和表达式引擎为 AI 场景的上下文感知权限控制奠定了基础

选型建议：

• 中小型项目：直接使用 Casbin 嵌入式库
• 大型分布式系统：Casbin + Redis Watcher + 分布式 Enforcer
• 云原生环境：评估 OPA Sidecar 方案，或 Casbin 服务化部署
• AI 应用：Casbin ABAC + 自定义上下文属性

未来展望：

随着 AI Agent 和自动化编程的普及，权限管理将不再是”配置即遗忘”的基础设施，而是需要持续学习、动态适应的智能系统。Casbin 的扩展性设计使其有能力适应这一演进，但社区也需要在 AI-Native 权限管理领域建立新的最佳实践和标准。

参考资料

• Casbin 官方文档：https://casbin.org/docs/overview
• Casbin GitHub：https://github.com/casbin/casbin
• OWASP LLM Top 10：https://owasp.org/www-project-top-10-for-large-language-model-applications/
• NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
• OPA 官方文档：https://www.openpolicyagent.org/docs/latest/
• SpiceDB 文档：https://authzed.com/docs

本文基于 Casbin v2.x 版本和 Go 1.22+ 环境撰写，部分代码示例经过简化以便阅读。

核心洞察：成都平原没有石头，所以每块石头都成了神。

一、一个反直觉的问题

成都平原，沃野千里。

这里土地肥沃、河网密布，是天府之国的核心。但如果你在这片平原上寻找天然巨石——抱歉，一块也找不到。

然而，当你翻开成都地图，满眼都是”石”：

• 支矶石街——与宽窄巷子一墙之隔
• 天涯石街——老东门的心脏地带
• 石笋街——宽窄巷子北面
• 五块石——火车北站附近
• 石羊场——成都南大门
• 石室中学——中国最早的官办学校
• 石经寺——龙泉驿的千年古刹

一座没有石头的城市，为何被石头命名？

这些石头从哪来？它们为何成为地标？又承载着怎样的文化记忆？

答案藏在三个层次的”石头叙事”里。

二、第一幕：神性的起源——石头是”天外来客”

支矶石：织女织机的垫脚石

西晋张华《博物志》记载了一个浪漫的故事。

汉代张骞出使大夏（今阿富汗北部）归来，从黄河源头带回一块石头，请教成都的严君平。严君平观后大惊：

“去年八月有客星犯牛郎、织女星，此石是天上织女的支矶石！”

原来，张骞在黄河源头见一女子织布、一男子放牛。女子说此地非人间，将垫在织机下的石头放入张骞船中，让他找严君平解惑。严君平夜观星象后确认——张骞竟到达了天河之畔。

这块石头，是织女织机下的垫脚石。

唐代岑参在《严君平卜肆》中追问：

“不知支机石，还在人间否？”

洞察：古人用神话解释一个事实——这块石头不属于这里。它的”外来性”本身就是神性的证明。

天涯石：女娲补天的遗落物

老成都流传着歌谣：

“清早起来不新鲜，心想成都耍几天。一出东门天涯石……”

这块粗红砂石，与支矶石并称古蜀文明”大石崇拜”的两大遗留物。

关于它的来历，有三个版本的传说：

1. 女娲补天说——遗落的五彩石
2. 天庭坠落说——玉皇大帝宫殿围栏上掉下的神石
3. 镇海眼说——古时这里有深洞每年涌水淹没城区，上天降巨石堵住

地质学家会告诉你：这是一块普通的粗红砂石，来自龙门山脉。

但古人选择相信神话。因为这块石头的”不可能存在”，本身就是奇迹。

三、第二幕：权力的密码——石头是”王者的墓碑”

石笋街：杜甫诗中的”双高蹲”

公元760年，杜甫在成都写下《石笋行》：

“君不见益州城西门，陌上石笋双高蹲。”

这证明至少在唐代，成都西门口竖立着一对形似石笋的高大石头。

但这对石笋在南宋时期悄然消失。

它们去哪了？为什么消失？没人知道。

但街名沿用至今，成为“看不见的地标”。

考古学的揭秘：大石崇拜与古蜀王墓

《华阳国志·蜀志》明确记载：

“蜀人以石笋为墓志。”

现代考古发现，古蜀人源于氐羌，而氐羌民族有悠久的“石棺葬”传统。在岷江上游，考古学家发现了大量先秦时期的石棺墓——用整块石板搭建的永恒居所。

成都平原的大石，或许是这种”大石崇拜”的延续。

• 天涯石、五块石、石笋——可能是古蜀王的墓前标志
• “五”在传统典籍中表示”无限”与”至尊”
• 巨石被赋予神圣意义，成为连接天地的象征

洞察：石头，是古蜀王与天地对话的媒介，是他们权力的纪念碑。

四、第三幕：文明的传承——石头是”不朽的誓言”

石室中学：中国最早的”石头学校”

公元前143-141年，蜀郡太守文翁创建”石室精舍”。

这是中国历史上第一所地方政府创办的高等学堂，文翁被誉为”中国历史上第一位校长”。

校舍主要由石头建造，故名”石室”。

班固《汉书》记载：

“蜀地学于京师者比齐鲁焉。”

杨慎赞曰：

“蜀学比于齐鲁”——把四川比作孔孟之乡。

司马相如、扬雄、郭沫若、李劼人……皆出自石室系统。

一块石头，撑起了一座城市的文脉。

后蜀石经：133万字刻于石上

五代后蜀广政七年（944年），宰相毋昭裔主持刊刻儒家经典于文翁石室。

历时200余年，贯穿后蜀、北宋、南宋、宋徽宗四朝，刻成”十三经”。

这是中国唯一带注文的石经——经文外镌刻双行注文，方便阅读理解。

这也是首次结集”十三经”——奠定中国儒学经典体系基本格局。

石逾千块，字数133万字以上。

学者誉为：

“冠天下而垂无穷”的壮举。

1938年，在文翁石室遗址发现残石，现仅存7块，四川博物院藏6块，被称为“一级文物中的一级”。

洞察：当石头从”神物”变为”教材”，成都人完成了一次文明的跃迁——把对永恒的崇拜，转化为对知识的信仰。

五、尾声：石头里的人文情怀

今天的成都人，或许已经不知道支矶石的故事。

但他们依然会在石室中学门口拍照打卡，会在宽窄巷子寻找那块被玻璃罩保护的”神石”，会在石经寺为家人祈福。

石头会风化，传说会淡忘，但那种对”永恒”的向往、对”知识”的敬畏，已经刻进了这座城市的基因。

正如岑参的那句追问：

“不知支机石，还在人间否？”

答案是：还在。

它不在文化公园的玻璃罩里，而在每一个成都人的文化记忆中——

在那条叫”支矶石街”的老巷里，在那所叫”石室中学”的校园里，在那座叫”石经寺”的古刹中。

成都平原没有石头，所以每块石头都成了神。

而这，就是成都。

附录：成都”石头地图”

参考资料：《华阳国志·蜀志》《博物志》《汉书》《成都城坊古迹考》

categories: 考古学

categories: 考古学

开始接触React。从 Antd 入手，了解react机制，了解typescript，同时在学习CocosCreator中熟悉typescript语法。

从scikit-learning到tensorflow

在使用Sencha(ExtJS6)的过程中遇到一个诡异的问题。

往TabPanel中添加一个Panel，添加的时候设置Panel的itemId，为了省事，直接用uuid生成的编号作为itemId的值。

诡异的事情发生了。 浏览器报错 ：　Ext.Component.constructor(): Invalid component “itemId”: “7490b8ce-a0c7-11e6-9eea-b8ca3a7c240a”

这个错误并不是每次必报，偶尔发生。刚开始怀疑是某些资源没有清理，但又找不到具体的问题。把itemId改为id，故障依然。最后跟踪代码，找到抛出异常的这段代码：

        //<debug>
        if (!me.validIdRe.test(me.id)) {
            Ext.raise('Invalid component "id": "' + me.id + '"');
        }
        if (!me.validIdRe.test(me.itemId)) {
            Ext.raise('Invalid component "itemId": "' + me.itemId + '"');
        }
        //</debug>

跟着查看了一下me.validIdRe的值：

        /^[a-z_][a-z0-9\-_]*$/i

明白了，itemId和id只能是字母或下划线开头。为itemId加个字母前缀，问题解决！

categories: 考古学

categories: 考古学

categories: 考古学

在豆瓣上看到一则评论，笑死我了。

  国家养研究生，盖同宋代养冗兵之意。养一百七十万研究生，则社会少一百七十万无业游民。且现在多是自费，国家不花分毫，仅一纸文凭，而买得海晏河清。这种制度设计，还有考研的人舍己为人的情怀真是令人激赞。

什么也别说，祖国知道我。

categories: 考古学

2015元旦快到了，希望能确立方向，顺利开题！