随着AI Agent的兴起,它们已成为代码阅读、重构和扩展过程中的常规组成部分。AI Agent正在逐渐成为继人类开发者、编译器和IDE之后的“第四个受众”。然而,与其他三者不同的是,目前还没有专门为AI Agent设计的、标准化的代码注释词汇系统。
为了解决这一痛点,一个名为agent-annotations-spec的新规范在GitHub上提出,其仓库地址是:https://github.com/codebasedlearning/agent-annotations-spec.git。
AI Agent理解代码的痛点
当AI Agent在一个多仓库的代码库中打开文件时,它只能看到文件本身。它无法自动识别出Python后端中的枚举类型必须与Kotlin移动客户端中的对应类型保持同步;也无法得知客户端的验证函数并非权威的强制执行点;更不会知道一个模块中的正则表达式模式隐式地约束着另一个模块中的构造函数。这些“硬核”知识,对于人类架构师来说是经过实践积累的上下文,但AI Agent却需要从命名和结构中自行推断,或者干脆推断错误。而且,在每一次新的会话中,Agent都需要从零开始重新构建这些上下文信息。
@agent注释协议旨在解决这个问题,它提供了一种约定俗成的方式,将这些隐含的知识显式地、内联地放置在代码所在的位置。
@agent注释示例
考虑两个不同语言、不同仓库中的枚举类型,它们之间没有共享接口。通过使用@agent注释,可以清晰地将它们关联起来:
# acme.hub / src / errors.py
# @agent sync "error-codes" Kept in sync manually — no codegen
class ErrorCode(enum.Enum):
NOT_FOUND = "not_found"
FORBIDDEN = "forbidden"
CONFLICT = "conflict"
// acme.clients / api / ErrorCode.kt
// @agent sync "error-codes"
enum class NameErrors(val value: String) {
NOT_FOUND("not_found"),
FORBIDDEN("forbidden"),
CONFLICT("conflict"),
}
无论是人类开发者还是AI Agent,当遇到其中任何一个文件时,都能立即知道另一个文件的存在,并理解它们的内容需要保持同步。这里没有URI、没有构建步骤、也没有Schema,仅仅通过标识符"error-codes"就建立了链接。
再看一个更重要的例子,它区分了“守卫(gate)”和“提示(hint)”之间的差异:
# @agent enforced-by "email-uniqueness" UI feedback only — server is the real gate; this check can be bypassed
def check_email_available(email: str) -> bool: ...
# @agent enforces "email-uniqueness" Authoritative — client check is UX only, never remove this
async def create_user(email: str, conn: asyncpg.Connection) -> User: ...
一个不了解这种区分的AI Agent,可能会错误地将服务器端的检查删除,认为它是多余的。这显然是一个严重的安全漏洞,而非简单的风格问题。
格式规范
@agent注释的通用格式如下:
@agent [command] [ident] [comment]
这种注释可以放置在任何行注释或文档字符串中,紧邻其所描述的符号。由于其仅依赖于编程语言的注释机制,因此兼容所有支持注释的语言,且无需任何特定工具。开发者甚至只需使用grep -r "@agent" .这样的命令即可查找和管理这些注释。