编码代理插件：无需离开终端即可管理你的架构

上个月，我看到我们团队的一位开发者做了一件感觉不应该行得通的事情。

他正在 Claude Code 中进行一次深度重构，把一个单体服务拆分成三个更小的服务。做到一半时，他输入了："在 Archyl 中创建三个新的容器——OrderService、InventoryService 和 NotificationService——放在 ECommerce 系统下。在 OrderService 和另外两个之间添加 'calls' 关系。"

十秒后，Archyl 中的 C4 model 就多了三个新容器，关系连接正确，精准地出现在架构中应有的位置。他没有切换标签页，没有打开浏览器，只是继续写代码。

那一刻，我意识到这个插件可以发布了。

上下文切换问题

架构文档有一个根本性的用户体验问题：它和代码不在同一个地方。

你正在 IDE 里。你刚刚重构了一个模块，重命名了三个服务，还把数据库拆分成了读写副本。代码写完了。现在你需要更新架构。这意味着你要在浏览器中打开 Archyl，找到正确的项目，导航到正确的图表，更新容器，添加关系，也许还要写一份 ADR 来解释你为什么做了这个改动。

这大概需要五分钟。但这五分钟有一个隐性成本：上下文切换。你的大脑必须离开代码，进入可视化图表模式，回忆你刚才做了什么，把它翻译成架构概念，然后再回去写代码。大多数开发者就……不做了。他们告诉自己以后再更新文档。以后永远不会来。

这就是架构漂移存在的原因。不是因为团队不在乎文档，而是因为工具在错误的时间出现在了错误的地方。

在你的对话中管理架构

Archyl Developer Plugin 将你的整个架构放入编码代理的上下文中。它是一个适用于 Claude Code 的插件（同时兼容 Codex 和其他代理），教会代理如何使用 Archyl 的全部 200 多个 MCP 工具。

这在实践中意味着什么？意味着你可以这样做：

重构时，告诉你的代理更新架构：

I just split the PaymentService into PaymentProcessor and PaymentGateway.
Update the architecture — remove the old container, create the two new ones,
and move all existing relationships to the appropriate new container.

审查代码时，询问架构上下文：

Get the full C4 model and tell me which components depend on the UserRepository.
Are there any conformance rules I should know about before changing the data layer?

规划工作时，检查文档是否仍然准确：

What's the current drift score? Show me which elements have drifted
and what the AI thinks is out of date.

设计会议之后，无需离开终端就记录决策：

Create an ADR: we decided to migrate from REST to gRPC for all internal
service communication. Context: latency requirements from the mobile team.
Link it to the ApiGateway and all backend service containers.

代理会处理 MCP 调用、管理项目 ID 并将操作串联在一起。你只需用自然语言描述你想要什么。

插件涵盖的内容

该插件为你的代理提供了七个领域的结构化知识：

C4 Modeling — 创建和管理系统、容器、组件、代码元素和关系。代理理解 C4 层级结构并强制执行正确的命名约定（系统和容器使用 PascalCase，代码元素使用精确的符号名称）。

文档 — 编写 ADR、创建项目文档、定义用户流程和审查 AI 生成的洞察。ADR 与其影响的 C4 元素相关联，因此架构决策始终与架构保持连接。

治理 — 创建合规性规则、运行合规检查和监控架构漂移。代理可以在 AI 编码会话开始之前就设置好防护栏。

运维 — 跨环境跟踪发布、记录 API 契约（OpenAPI、gRPC、GraphQL）、映射事件通道（Kafka、NATS、SQS）以及管理技术雷达。

协作 — 添加评论、创建变更请求（类似于架构的 PR）和管理白板。架构讨论发生在代码讨论发生的地方。

历史 — 拍摄快照、在架构版本间时间旅行以及对比变更。当有人问"迁移之前架构是什么样的？"时，代理可以回答。

集成 — 配置架构变更通知的 webhook、管理市场小部件以及查看组织中所有项目的全局架构。

三步完成设置

设置过程非常简单：

1. 添加市场并安装插件：

/plugin marketplace add archyl-com/agent-skills
/plugin install archyl-developer@archyl-com-agent-skills

2. 将 MCP 服务器添加到你项目的 .mcp.json 中：

{
    "mcpServers": {
        "archyl": {
            "type": "http",
            "url": "https://api.archyl.com/mcp",
            "headers": {
                "X-API-Key": "arch_your_api_key_here"
            }
        }
    }
}

3. 重启你的代理，开始与你的架构对话。

就是这样。插件会自动加载，代理知道如何使用每一个工具。不需要配置文件，不需要自定义提示词，不需要手动接线。

为什么选择开源

该插件完全开源，地址是 github.com/archyl-com/agent-skills。有几个原因。

首先是透明性。当一个插件教 AI 代理如何与你的架构交互时，你应该能够阅读它给出的每一条指令。技能定义、参考文件、工作流示例——都在那里，以纯 markdown 的形式。

其次是贡献。Archyl 有超过 200 个 MCP 工具，最好的工作流来自真实的使用场景。当一个团队发现了一个有效的模式——比如在重大发布之前审计架构的工作流——他们可以将其贡献回来。插件因为社区的使用而变得更好。

第三是可移植性。技能内容不局限于 Claude Code。它可以与任何支持插件格式的代理一起使用。.claude-plugin 和 .codex-plugin 清单文件都已包含在内。如果下个月出现一个支持插件的新编码代理，技能内容可以直接转移。

改变了什么

这个转变微妙但意义重大。

在有插件之前，架构文档是一个独立的活动。你写代码，然后记录文档。两个工作流，两个工具，两种思维模式。文档总是落后一步，因为它总是隔了一步。

有了插件之后，架构文档成为编码对话的一部分。你不需要"更新文档"——你只需提到什么发生了变化，代理就会处理。架构保持同步不是因为有人记得去更新它，而是因为更新它变得毫不费力。

这在代理工作流中尤其强大。当 AI 代理在对你的代码库进行更改时，它可以同时更新架构。重构代码的同一个会话也可以更新 C4 model、记录 ADR 并运行合规性检查。架构治理成为开发流程的自然组成部分，而不是事后补救。

开始使用

安装插件，连接你的 MCP 服务器，然后试着让你的代理描述你的架构。然后让它做一个修改。当你第一次从终端对话中更新 C4 model 时，你会想为什么以前不是这样做的。

插件现在就可以使用。完整文档在我们的指南中，源代码在 GitHub 上。

你的架构不应该存在于另一个标签页中。现在它不必了。