从 Cursor 到 Claude Code，告别 AI 编程工具 Agent 配置烦恼，下一代通用 Agent 规范语言 ASL 详解

本文将系统梳理 8 种主流 AI 编程工具的配置机制，深入分析当前各类编程 Agent 所采用的不同指令体系。在此基础上，引出 OpenAI 发起的编码 Agent 指引规范 —— AGENTS.md，并尝试将其扩展至项目管理、设计、市场等非编码 Agent 领域，最终构建一种通用的 Agent 规范语言（Agent Specification Language，简称 ASL），实现各类 Agent 约束规则的自动化生成。

大家是否注意到，无论是早前流行的 Cursor，还是近期备受关注的 Claude Code，以及在非开发者群体中知名度较低的 Aider、RooCode、Amp 等 AI 编程工具，每种工具都自带一套独特的指令配置方法（如 .cursor/rules/、GEMINI.md、claude.md 等）进入市场。这种多样性虽体现了各开发团队的创新理念，但也带来了生态系统的碎片化问题。

开发者因此不得不学习并维护大量专有格式的配置文件，以有效指导不同 AI 工具完成任务。这些配置文件的核心目标，是向 AI 编程工具清晰传达复杂的项目背景、领域知识及行为约束。然而，当项目在不同工具间切换时，这种沟通的复杂性被进一步放大——因为为某一工具精心设计的指令文件，在另一工具上可能完全无效。

AI 编程工具 Agent 规范比较分析

当前，不同的 AI 编程工具在指导编码 Agent 行为方面，沿着多个方向独立发展。这些方法大致可分为三类：强调机器可读性的结构化方法、注重人类可读性的启发式方法，以及将复杂配置抽象为角色的“人格化”方法。这三类方法并无优劣之分，而是反映了各产品在实现人机高效协作过程中所采取的不同设计理念与权衡策略，有的产品将三种方法进行了结合。

AI 编程工具	主要配置文件/文件	格式	核心指令概念
Aider	.aider.conf.yml, CONVENTIONS.md	YAML, Markdown	结构化配置与启发式规则的结合
Amp	settings.json (VS Code)	JSON	结构化配置（命令白名单，MCP 服务器）
Cursor	.cursor/rules/, .mdc	Markdown with Metadata	分层、情境感知的启发式规则
Gemini CLI	settings.json, GEMINI.md, .toml	JSON, Markdown, TOML	结构化设置与可定制的提示模板
Jules	AGENTS.md, (UI 配置)	Markdown	启发式指导，早期采纳AGENTS.md
Kilo Code / RooCode	custom_modes.json, .roo/rules/	JSON, Markdown	人格化（Modes），高度可定制
OpenCode	opencode.jsonc	JSONC	结构化配置，强调权限和安全
Zed	.rules	Plain Text / Markdown	项目级的全局启发式规则

结构化方法：强调机器可读性

这类 Agent 依赖于高度结构化、机器可读的格式，如 YAML、JSON 或 TOML，来进行配置。这种方法的优势在于能够精确地定义操作参数、模型选择、工具权限和行为边界，为 Agent 的运行提供了明确且无歧义的指令。然而，它在传达细微的、自然语言形式的指导（如编码风格或架构原则）方面则显得力不从心。

• **Aider (.aider.conf.yml)**：使用 YAML 文件（.aider.conf.yml）来管理其行为的方方面面。开发者可以通过该文件指定用于主聊天的模型、配置 Git 提交行为（例如，是否将 aider 添加为共同作者）、设置自动执行的 linting 命令以及定义测试命令 ，这种深度可配置性反映了一种以开发者为中心的设计理念，即通过精确的参数控制来确保 Agent 的行为符合项目的技术规范和工作流程。

• **OpenCode (opencode.jsonc)**：OpenCode 采用了 JSONC（带注释的 JSON）格式，提供了一个强大且安全的配置系统。其opencode.jsonc文件不仅可以定义不同 Agent（如build和plan）应使用的特定模型，还能通过变量替换（例如，使用{env:VARIABLE_NAME}引用环境变量）来灵活管理敏感信息，如 API 密钥。尤为突出的是其精细的权限系统，允许开发者为关键操作（如文件编辑edit或执行 shell 命令bash）设置明确的审批要求，例如"ask"（需要用户批准）或"allow"（自动批准）。这表明 OpenCode 在设计上高度重视安全性和灵活性，力求在赋予 Agent 自主性的同时，将最终控制权交还给开发者。

• **Gemini CLI (settings.json, .toml)**：Google 的 Gemini CLI 展示了一种混合的结构化方法。它使用一个settings.json文件来配置核心工具级设置，例如沙箱环境（需要 Docker 或 Podman 支持）、启用的模型上下文协议（MCP）服务器以及是否自动接受工具调用等。与此同时，它还允许用户在.gemini/commands/目录下创建.toml文件来定义自定义的斜杠命令。每个.toml文件包含一个描述和一个详细的提示（prompt），可以将复杂的指令封装成一个简单的命令（如/plan），极大地提高了交互效率。这种组合方式试图在系统级配置的严谨性和用户级指令的灵活性之间取得平衡。

启发式方法：优先考虑人类可读性

与结构化方法相对，启发式方法优先考虑使用自然语言，通常是通过 Markdown 文件来传达指令。这种方法更易于人类编写和理解，尤其适合捕捉那些难以用代码或参数量化的定性指南，例如编码风格、架构哲学或领域特定知识。

• **Cursor (.cursor/rules, .mdc)**：Cursor 的规则系统是启发式方法中一个非常成熟的实现。它使用.cursor/rules目录中的.mdc（Markdown with Components）文件来存储规则。这些规则文件不仅包含 Markdown 格式的自然语言指令，还支持元数据，用于控制规则的应用方式（例如，alwaysApply或根据文件 glob 模式自动附加）。更进一步，Cursor 支持嵌套规则，允许在项目的不同子目录中定义特定的规则，当 Agent 处理该目录下的文件时，最接近的规则集将自动生效。这套复杂的系统使得编码特定领域的知识成为可能，例如，可以为前端组件库定义一套规则，为后端 API 定义另一套，从而实现高度情境化的 AI 指导。

• **Aider (CONVENTIONS.md)**：与 Cursor 的复杂系统相比，Aider 提供了一种更为轻量级的启发式指导方式。开发者可以创建一个名为CONVENTIONS.md的 Markdown 文件，并在其中列出编码约定。例如，文件中可以指明“优先使用httpx而非requests进行 HTTP 请求”以及“尽可能使用类型提示” 。当通过/read CONVENTIONS.md命令将此文件加载到聊天会话中时，Agent 在后续生成代码时会遵循这些约定。这种方法的简洁性使其易于采用，同时在引导 Agent 遵循项目特定风格方面非常有效。

• **Zed (.rules)**： Zed 编辑器内置的 AI Agent 同样支持在项目根目录下放置一个.rules文件。该文件中的内容会作为项目级别的指令，被包含在与 Agent 的每一次交互中。这种方法类似于 Cursor 的全局规则，但实现上更为直接和简单，为开发者提供了一种快速注入持久性上下文的方式。

人格化方法：基于角色的系统

第三种方法是将复杂的配置和指令集抽象为“人格”（Personas）。这种方法通过将系统提示、可用工具和权限整合为基于角色的原型，显著简化了用户体验。用户只需选择合适的人格角色，而无需了解底层的复杂配置。当 AI Agent 功能强大时，管理其复杂性本身就会成为用户体验的挑战。将这些能力封装为易于理解的角色（如“架构师”），为用户提供了直观的心理模型，从而成为一种高效的设计方案。

• Kilo Code / RooCode：这两个 VS Code 扩展在“模式”概念的实现上非常丰富。它们预置了多种模式，例如 Code（通用编码）、Architect（系统设计）、Debug（错误排查）和 Orchestrator（任务协调）。每种模式不仅包含特定的系统提示，还被赋予不同的工具访问权限。例如，Architect 模式可能仅允许读取文件和浏览网页，而不能修改代码或执行终端命令，从而确保其专注于高层规划。用户也可以创建自定义模式，定义新的“人格”，并为其分配特定的指令和工具集，从而实现对 Agent 行为的高度定制。

• Aider：Aider 也实现了模式系统，比 Kilo Code 简化。它提供三种模式：code、ask 和 architect。在 code 模式下，Agent 直接修改代码；在 ask 模式下，Agent 仅参与讨论和问答，不修改文件；而在 architect 模式中，采用两阶段流程：首先由一个“架构师”模型提出修改建议，再由一个“编辑器”模型将其转化为具体的代码修改指令。

• Claude Code：Claude Code 的子代理功能，每个子代理在 Markdown 文件中定义，具有以下结构：

  字段	必需	描述
  name	是	使用小写字母和连字符的唯一标识符
  description	是	子代理目的的自然语言描述
  tools	否	特定工具的逗号分隔列表。如果省略，从主线程继承所有工具

总结

结构化配置格式（如 YAML 或 JSON）能够提供机器执行所需的精确性和安全性，而非结构化指令（如 Markdown）则更适合表达人类协作所需的语境和意图。目前的工具往往偏向其中一方面，或者像 Gemini CLI 那样尝试通过混合系统来弥合二者之间的鸿沟。不过目前尚无一种通用方案能够优雅地统一这两类方式。在 Agent 能力快速演进的过程中，安全性问题常常被忽视。例如，Amp Code 中曾发现一个严重的安全漏洞（详见 相关报告），攻击者可通过提示注入手段修改 Agent 的 settings.json 配置文件，从而将恶意命令加入白名单，或注册恶意的 MCP 服务器，最终实现任意代码执行。这个漏洞揭示了一个关键的设计缺陷：Agent 的操作范围（即可读写文件的权限）与其自身配置的管理范围未被有效隔离。因此，一个完善的 Agent 规范不仅应能定义其权限边界，还应确保该规范本身处于 Agent 的只读范围内，以防止其进行自我授权。

AGENTS.md 规范出现

AGENTS.md 规范由 OpenAI 发起，其核心设计理念是简洁与可预测性。该规范通过定义一种通用、非专有的格式，使代码库能够以标准化方式对接任何兼容的 AI 编程工具。目前，已有多个产品宣布将在后续版本中支持 AGENTS.md。

简单与可预测

该规范选择标准 Markdown 作为其格式，这是一个深思熟虑的设计决策。Markdown 语法简单，人类易于读写，同时对于机器来说也足够结构化，便于解析。通过约定一个固定的文件名AGENTS.md并将其放置在项目根目录，该协议为所有 Agent 提供了一个明确且可预测的根约束，Agent 不再需要在代码库中猜测指令的位置。

最佳实践结构

虽然 AGENTS.md 规范是灵活的，没有强制要求的字段，但社区已经形成了一套推荐的最佳实践结构。一个典型的AGENTS.md文件通常包含以下几个部分，每个部分都服务于向 Agent 传达特定类型的上下文：

• **项目概览与架构 (Project Overview & Architecture)**：简要描述项目的目标、核心功能和技术栈。例如，“这是一个使用 TypeScript 前端和 Node.js 后端的全栈 Web 应用”，这能帮助 Agent 快速建立对代码库的宏观理解。

• **构建、测试和开发命令 (Build, Test, and Development Commands)**：列出所有关键的脚本命令，如安装依赖（pnpm install）、运行测试（pnpm test）、启动开发服务器（pnpm dev）等。这使得 Agent 能够自主执行验证、构建和测试流程。

• **代码风格与约定 (Code Style and Conventions)**：明确项目的编码规范，例如，“使用单引号，不使用分号”或“测试文件名必须以.test.ts结尾”。这些指令有助于 Agent 生成的代码与现有代码库风格保持一致。

• **测试指南 (Testing Guidelines)**：提供关于如何运行特定测试、查找持续集成（CI）计划以及如何修复常见测试失败的更详细说明。这对于需要自主调试和修复问题的 Agent 至关重要。

• **安全注意事项 (Security Considerations)**：列出项目相关的安全准则，例如，“绝不将密钥或 API 令牌提交到仓库”或“所有用户输入都必须经过严格验证”。

• 分层应用：为了适应大型单体仓库（monorepo）的复杂性，AGENTS.md规范支持嵌套。开发者可以在子项目或子目录中放置额外的AGENTS.md文件。当 Agent 在特定目录下工作时，它会使用目录树中离它最近的那个AGENTS.md文件，该文件的指令会覆盖上层目录中的通用指令。这种分层机制允许为项目的不同部分提供更细粒度的指导。

AGENTS.md 是一组声明式配置，一个 YAML 配置文件可能会命令 Agent 执行lint-cmd："eslint. --fix" ，这是一个具体的、命令式的指令，而一个AGENTS.md文件则会声明一个可用的操作：“修复格式问题：pnpm check:fix” ，后者要求 Agent 的推理时理解这个声明，并将其作为解决更广泛问题（例如，“修复代码中的所有 lint 错误”）的一个可用工具。

AGENTS.md 生态

一个标准的成功与否，最终取决于其在生态系统中的采纳程度和带来的价值，该协议已经获得了一些重要工具的支持，Google 的 Jules Agent 明确在其文档中指出，它会自动查找并使用仓库根目录下的AGENTS.md文件，以更好地理解代码并生成更相关的计划。同样，功能强大的Cursor IDE 也支持AGENTS.md作为其项目规则的一种简单替代方案 。Amp Code 的开发者积极倡导这一标准，并提供了将其他专有配置文件迁移到AGENTS.md的指南。

与模型上下文协议（MCP）的共生关系，MCP 是一个用于定义工具能力和输入/输出模式的标准，它允许 Agent 在运行时动态发现和调用工具。如果说AGENTS.md定义了 Agent 的意图和知识（“做什么”和“为什么这么做”），那么 MCP 则定义了 Agent 的能力和工具（“如何做”）。Agent 通过 AGENTS.md理解任务目标和项目上下文，然后通过 MCP 发现并调用完成任务所需的工具（无论是本地脚本还是远程 API）。

对于开发者，实现“一次编写，随处运行”。开发者只需维护一个AGENTS.md文件，就能为任何兼容的 Agent 提供丰富的项目上下文，极大地降低了在不同工具间切换的成本。

这种标准化也带来了一种重要的架构解耦：Agent 知识与 Agent 核心逻辑的分离。在AGENTS.md出现之前，提升 Agent 在特定代码库中表现的方法可能包括工具 UI 中编写复杂的自定义提示，而现在，这些项目特定的知识被外化到了一个与代码一同版本控制的AGENTS.md文件中。

一种通用的 Agent 规范语言（ASL）

超越代码：构建领域无关的 Agent 规范

AGENTS.md 规范旨在缓解 AI 编程领域中指令碎片化问题，但其价值不仅限于代码编写。定义 AI Agent 的核心挑战——明确其身份、目标、知识、工具和边界——是跨领域普遍存在的问题。以“文本形式指导”为核心的 AGENTS.md 范式，具备向市场、设计和项目管理等非编程领域扩展的潜力。随着 Agent 在各行业的深入应用，处理非编码领域复杂任务所需的指令结构，将远超当前 AGENTS.md 所能提供的 Markdown 格式所能表达的范畴。因此，下一步的自然演进是设计一种更加正式、结构化且可扩展的通用 Agent 规范语言（Agent Specification Language, ASL），这种语言将成为构建跨领域、可互操作的 Agent 生态系统的基础。

通用 Agent 规范语言（ASL）的核心原则

ASL 的设计目标是成为 AGENTS.md 理念的超集，在保留其高可读性这一核心优势的同时，提供一种结构严谨、模块化且易于扩展的语法体系。一种可能的实现方式是采用带有 YAML frontmatter 的结构化 Markdown，或设计一种可编译为优化提示的领域特定语言（DSL）。以下是 ASL 的核心组成模块：

Persona 模块

“Persona” 这个词在不同语境下有不同翻译，可以结合场景选最合适的，为 Agent 定义一个清晰的身份。

语境	翻译	说明
用户研究 / 产品设计	用户画像	常见于 UX 设计、营销领域，用于描述典型用户的特征、行为、动机
游戏 / 虚拟角色	角色 / 化身	指游戏或故事中的人物设定
心理学（荣格）	人格面具	指个体在社会中展示给他人的人格面貌
品牌 / IP 定位	品牌人设 / 角色设定	在社交媒体和品牌营销中常用，表示拟人化的品牌个性
AI/聊天机器人	角色设定 / 人设	表示机器人或 Agent 的性格、口吻、知识范围

• identity：Agent 的名称和角色（例如：“UI 设计师”、“增长黑客”）。
• tone_of_voice：描述其沟通风格的形容词。
• core_function：一句高层次的使命宣言，概括其核心职责。

这个设计直接受 Factory 的 Droids 和 Kilo/RooCode 的 Modes 的启发，将已被验证的用户体验模式提升为一等特性。

Goals & Objectives（目标与目的）模块

此模块用于明确定义任务的成功标准，将用户的隐性意图转化为 Agent 可以理解和衡量的显性目标。

• primary_goal：最终期望达成的结果。
• key_results：可量化的成功指标，相当于 Agent 的 OKR（目标与关键成果）。
• success_criteria / definition_of_done：定性的完成条件。

这是对用户自然语言提示的一种形式化，旨在减少歧义，使 Agent 的行为更加目标导向。

Knowledge & Context（知识与上下文）模块

此模块用于界定 Agent 的世界观，明确其可以访问和依赖的信息来源。

• sources：指向文件、目录、URL 或 API 的引用列表，作为 Agent 的知识库。例如：@./brand-guidelines.pdf, @https://api.example.com/docs。
• initial_instructions：核心的自然语言指令，类似于AGENTS.md的主体内容，用于描述具体的工作流程和指导原则。

这是对Aider 的CONVENTIONS.md 和 Gemini CLI 的GEMINI.md导入功能 以及Cursor 的@file上下文引用 的整合。

Tools & Capabilities（工具与能力）模块

此模块用于声明 Agent 可以执行的动作，明确其能力边界。

• enabled_tools：一个显式的工具列表，指明 Agent 被授权使用的能力（例如：[email, calendar, web_search, file_edit]）。
• mcp_endpoints：Agent 可以连接的 MCP 服务器列表，用于获取自定义或外部工具。

提供了一个直接的 MCP 集成点，并形式化了在OpenCode 和RooCode 等工具中看到的工具权限管理机制。

Rules & Constraints(规则与约束）模块

此模块用于建立行为护栏，确保 Agent 在自主操作时的安全性和合规性。

• must_do：必须遵守的正面指令。
• must_not_do：严格的禁止性规定（例如：“禁止使用受版权保护的图片”）。
• permissions：对敏感操作的精细化控制，可设置为需要用户批准（例如：send_email："ask"）。

综合了 Cursor 的规则、Zed 的规则 和OpenCode 的权限系统 ，并将其提升为核心特性。

ASL 实践：领域特定的实现

为展示 ASL 的灵活性与实用性，以下将为三个不同角色创建假设但符合实际的 ASL 规范示例。

设计领域：brand-guardian.asl 规范

角色设定:
  身份：品牌守护者
  语气：权威、精准、富有创意
  核心职能："确保所有对外发布的素材 100% 符合公司的品牌规范。"

目标:
  主要目标："在所有线上和线下物料中，保持品牌形象的一致性。"
  关键成果:
    - "将营销活动中的不合规素材减少 95%。"
    - "素材审批周期控制在 24 小时以内。"
  完成标准："如果一项素材正确使用了官方指定的 Logo、字体、调色板和图像，即可被视为合规。"

知识库与背景信息:
  知识来源:
    - "@./brand_guidelines_v4.pdf"
    - "@./logo_assets_v3/"
    - "@./approved_font_files/"
    - "@./marketing_campaign_archive/"
  初始指令：|
    你的任务是审核新提交的设计素材。
    1. 对照知识库中的参考资料，分析待审素材。
    2. 检查 Logo 使用是否正确、配色是否遵循调色板规范 (主色与辅助色) 、以及是否应用了官方指定字体。
    3. 如果合规，则批准该素材。
    4. 如果不合规，需提供具体的、可行的修改建议，并明确指出其违反了品牌规范的哪一章节。

工具与能力:
  已启用的工具:
    - 文件读取 (file_read)
    - 图像分析 (image_analysis)
    - 调色板检查器 (color_palette_checker)
    - PDF 解析器 (pdf_parser)

规则与限制:
  禁止行为:
    - "绝对禁止批准任何使用了已弃用十六进制颜色代码 #FF00FF 的素材。"
    - "绝对禁止提出修改品牌规范的建议；你的职责是执行，而非创造。"
  权限:
    批准素材："允许"
    驳回并附上反馈："允许"
    建议重新设计 Logo："需人工确认"

市场领域：growth-hacker.asl 规范

角色设定:
  身份：增长黑客 (Growth Hacker)
  语气：数据驱动、勇于实验、大胆、简洁
  核心职能："设计、执行并分析一系列快速实验，以驱动用户拉新和提升活跃度。"

目标:
  主要目标："实现新用户注册量每月 5% 的环比增长。"
  关键成果:
    - "每月至少发起 4 项新的 A/B 测试。"
    - "确保 75% 的测试都能获得具备统计学意义的结果 (无论正面或负面)。"
  完成标准："一项实验需在完成结果分析、归档记录，并为后续步骤 (全面推广、迭代优化或直接放弃) 给出明确建议后，才算正式完成。"

知识库与背景信息:
  知识来源:
    - "@https://analytics.example.com/api"
    - "@./past_ab_test_results.csv"
    - "@./user_personas.md"
  初始指令：|
    请基于最新的分析数据和过往的实验结果，提出一项新的增长实验方案。
    1. 提出一个清晰的假设 (例如：“将行为召唤 (CTA) 按钮的颜色从蓝色改为绿色，点击率将提升 10%”)。
    2. 明确定义实验的目标用户和衡量成功的关键指标。
    3. 使用 A/B 测试工具，简述实验的具体执行步骤。

工具与能力:
  已启用的工具:
    - 网络搜索 (web_search)
    - 社交媒体发布工具 (social_media_poster)
    - A/B 测试配置工具 (ab_test_setup_tool)
    - 数据分析 (data_analysis)
    - SQL 查询工具 (sql_query_runner)

规则与限制:
  强制要求:
    - "在发起任何测试之前，都必须先提出一个清晰且可被证伪的假设。"
  禁止行为:
    - "未经明确批准，绝对禁止针对现有付费用户开展任何实验。"
  权限:
    发起预算低于 1000 元的实验："允许"
    发起预算超过 1000 元的实验："需人工确认"
    发布内容至社交媒体："需人工确认"

项目管理领域：project-owner.asl 规范

角色设定:
  身份：项目负责人
  语气：有条不紊、清晰明确、直接了当、坚韧不拔
  核心职能："确保所有软件项目在规定范围内按时上线，并符合‘完成’的标准。"

目标:
  主要目标："在本季度结束前，成功将‘凤凰项目 (Phoenix Project)’部署到生产环境。"
  关键成果:
    - "部署前完成发布清单 (release checklist) 中 98% 的检查项。"
    - "发布 24 小时内，严重级别 (critical) 的 Bug 报告数量为零。"
  完成标准："项目成功上线生产环境、部署后监控显示系统性能稳定、且已发送上线公告，才视为项目已交付。"

知识库与背景信息:
  知识来源:
    - "@https://jira.example.com/api"
    - "@./release_checklist_template.md"
    - "@./on_call_schedule.csv"
  初始指令：|
    今天是“凤凰项目”的预定发布日。
    1. 从模板获取最新的发布清单。
    2. 通过查询 Jira 和持续集成/持续部署 (CI/CD) 系统，逐一核实清单中各事项的状态。
    3. 若所有事项均已完成，则按照标准流程执行部署。
    4. 若有任何事项未完成，应立即标记、通知相关负责人，并中止发布流程。

工具与能力:
  已启用的工具:
    - 日历 (calendar)
    - 工单创建工具 (ticket_creator)
    - Git 版本标记工具 (git_tagger)
    - 部署触发器 (deployment_trigger)
    - Slack 通知工具 (slack_notifier)

规则与限制:
  强制要求:
    - "在触发部署前，必须确认发布清单上的所有检查项都已完成。"
  禁止行为:
    - "若有任何自动化测试未通过，绝对禁止执行部署。"
  权限:
    触发部署："需人工确认"
    创建 Jira 工单："允许"
    标记 Git 发布版本："允许"
    发送飞书通知："允许"
    中止发布："允许"

通往可互操作的 Agent 生态系统

ASL 的实现远不止于创建一个更优秀的配置文件格式。我将其设想为一种通用的“AI 劳动力操作系统”。在这一模型中，企业通过 .asl 文件定义并分配任务，从而在人类意图与 AI 操作执行之间建立桥梁。这种统一的规范语言为企业实现大规模协调、治理和自动化扩展提供了标准化框架。

• Agent 能力市场：组织无需自行开发或深度定制 Agent。只需使用 ASL 精确描述工作需求，即可从开放市场中选择最高效、最可靠的 Agent 服务提供商。
• 可组合的 Agent 协作：复杂的跨职能工作流成为可能。例如，由 project-owner.asl 驱动的“项目交付 Agent”可在需要时，自动将设计审查任务委托给由 brand-guardian.asl 控制的“品牌守护 Agent”。每个 Agent 在其专业领域内运行，并通过统一的规范语言进行交互，从而实现无缝协作。
• 可执行的知识管理：企业的核心知识，如品牌指南、安全策略、合规流程等，将不再是以静态文本形式存储在文档库中。它们将被编码为可执行的 ASL 文件，直接指导和约束企业内所有 AI Agent 的行为。这种方式确保了知识在传递和应用过程中的一致性与准确性，将知识管理提升至一个全新的动态、可治理的水平。

实现这一愿景的同时，也预示着一种新型专业角色的诞生。编写和维护能够精准表达复杂业务流程与领域专长的 ASL 文件，是一项兼具技术深度和业务洞察力的挑战性工作。这将催生“Agent 架构师”或“AI 交互设计师”等新角色。他们的职责是作为人类专家与 AI 执行者之间的桥梁，将隐性的业务智慧转化为机器可明确理解和执行的规范。

结语

这篇文章的诞生源于我在深度使用 Claude Code 的 subagent 功能、创建了 100 多个 Agent 后的顿悟：Claude Code 并不仅仅是一个编码 Agent 工具，它更像是一种下一代操作系统（OS）的雏形。我将 Claude Code 部署在一台 Debian 系统上（未安装所有日常办公软件），通过 MCP 协议或自定义的 bash 命令（底层由 Python 实现并调用第三方工具的 API）完成日常任务，整个过程出乎意料地流畅。

从 AGENTS.md 到 ASL 的演进，标志着从解决具体技术问题（代码 Agent 的配置）逐步发展为构建一个通用、可赋能所有知识工作的协作框架的尝试。即使 ASL 未必成为最终的实现形式，类似的规范也必将出现，并引领我们进入一个全新的时代：AI Agent 将不再是简单的工具，而是成为可靠、可控且可组合的数字化团队成员。

如果觉得内容不错，欢迎点个关注，分享和在看～