如何编写可复用AI AgentCompozyOS的AGENT.md与SOUL.md完全教程【免费下载链接】compozyAn operating system for AI agents. Plug in the agent CLIs you already use (Claude Code, Codex, Gemini CLI, Cursor) and they become a team: they split the work, hand tasks to each other, run automated on jobs and loops, and share one project memory. You steer everything from the browser.项目地址: https://gitcode.com/gh_mirrors/co/compozyCompozyOS 是一个「AI Agent 操作系统」把你已在用的 Agent CLIClaude Code、Codex、Gemini CLI、Cursor插进来它们就组成一支团队——分工协作、交接任务、运行自动化 Job 与 Loop并共享同一份项目记忆。而让每个 Agent 可定义、可复用、可继承的核心就是两个 Markdown 文件AGENT.md定义角色与权限和SOUL.md定义人格与行为边界。本文教你快速上手。AI Agent 定义文件的分工AGENT.md 管「职责」SOUL.md 管「性格」在 CompozyOS 中一个 Agent 由目录承载目录里通常只有两个文件文件作用类比AGENT.md角色定位、权限级别、分类归属工牌你是谁、能做什么SOUL.md语气、原则、约束、协作方式、记忆策略性格你说话做事的风格这种分离设计的价值在于复用同一个角色的 Agent 可以换不同的「灵魂」来适配不同项目也可以给不同角色注入同一套团队文化。解析与校验逻辑在 internal/soul/ 源码中其中 soul.go 定义了SOUL.md的规范化结构Profile、Frontmatter等。编写 AGENT.md三步定义一个可复用 Agent第一步建目录Agent 采用「一人一目录」组织。用户级 Agent 放在工作区的.compozy/agents/agent名/下例如.compozy/agents/marketing/ └── AGENT.md第二步写 frontmatter 元数据参考 marketing Agent 的真实写法--- name: marketing permissions: approve-all category_path: - Marketing ---nameAgent 名称用于在团队中调用permissions权限级别决定它执行操作时是否需要审批category_path分类路径用于在界面中归类第三步用一两句话写清角色正文不必长篇大论关键是说清两件事它是什么专家、依据什么做事。以 marketing Agent 为例正文就一句作为 CompozyOS 的市场专家使用与请求匹配的 agent-local skills并保持对外文案与COPY.md一致。 提示写得越聚焦Agent 在团队中的分工越清晰。对比另一个实例 pr-release-reviewer它专注发布前审查这一件事。编写 SOUL.md给 Agent 注入一致的「性格」SOUL.md与AGENT.md放在同一目录。它由两部分组成YAML frontmatter允许字段白名单 Markdown 正文人设描述。支持的 frontmatter 字段字段说明version灵魂版本便于迭代追踪role一句话角色定位tone语气列表如「简洁、直接」principles行为原则constraints硬约束红线collaboration与其他 Agent 的协作方式memory_policy记忆读写策略tags标签便于检索一个精简示例--- version: 1 role: 代码审查专家 tone: [直接, 建设性] principles: [先给结论再给理由] constraints: [不修改源代码] --- 你是一位资深审查者关注可读性与边界条件……写 SOUL.md 的两个「坑」字段白名单frontmatter 中出现未列入白名单的字段会被拒绝并给出带行号的诊断信息见 soul_parse.go。正文体积上限正文超过agents.soul.max_body_bytes配置会报oversized_body诊断。人设要「精炼」不是「写小说」。解析后的SOUL.md会生成内容摘要digest当它变化时运行时能感知到灵魂更新——这意味着你可以持续迭代 Agent 的性格而不影响其角色定义。从示例看复用一个 Agent 目录如何被整个团队共享项目里最有说服力的复用案例是spec-cycle 扩展它在 extensions/spec-cycle/agents/ 下定义了四个协作角色——orchestrator总编排code_implementer负责实现reviewer负责评审review_fixer负责按评审意见修复这四个 Agent 配合扩展中的 loops 与 skills构成一条「规格 → 实现 → 评审 → 修复」的可循环流水线。同理open-design 扩展 也自带 designer 与 critic 两个 Agent。覆盖顺序让 Agent 层层进化CompozyOS 的加载优先级为Bundled → Marketplace → User → Profile → Additional → Workspace → Workspace-Profile → Agent-local详见 internal/AGENTS.md这意味着同一个 Agent 可以在不同工作区被「微调」工作区级配置覆盖用户级配置Agent 本地配置拥有最高优先级。这正是「可复用」的工程化落地——定义一次处处生效局部定制。快速自检清单写完后对照检查✅ Agent 目录名与 frontmattername一致✅AGENT.md正文说清了「是什么专家 依据什么工作」✅SOUL.mdfrontmatter 只使用白名单字段无拼写错误✅ 约束constraints写的是「红线」而非「建议」✅ 正文精简未超过体积上限✅ 复用场景下确认你的配置落在正确的覆盖层级总结在 CompozyOS 中AGENT.md 定义职责SOUL.md 定义性格目录结构承载复用覆盖顺序支撑定制。两份 Markdown 文件即可让一个 AI Agent 从「一次性脚本」变成可分发给整个团队、跨工作区复用的标准化组件。想深入理解校验机制可以从 internal/soul/soul.go 的ResolveRequest结构读起。【免费下载链接】compozyAn operating system for AI agents. Plug in the agent CLIs you already use (Claude Code, Codex, Gemini CLI, Cursor) and they become a team: they split the work, hand tasks to each other, run automated on jobs and loops, and share one project memory. You steer everything from the browser.项目地址: https://gitcode.com/gh_mirrors/co/compozy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考