> ## Documentation Index
> Fetch the complete documentation index at: https://acp-docs.cxykevin.top/llms.txt
> Use this file to discover all available pages before exploring further.

# 对话请求 (RFDs)

> 我们引入协议变更的流程

"对话请求" (RFD) 是ACP版本的RFC流程。RFD是提议新功能、收集社区对问题的意见以及记录设计决策的主要机制。

## 何时编写RFD

如果您打算对ACP或其文档进行"重大"更改，应考虑编写RFD。什么构成"重大"更改正在根据社区规范不断发展，并根据您提议更改的生态系统的部分而有所不同。

某些更改不需要RFD：

* 重新表述、重组或重构
* 添加或删除警告
* 严格改善客观、数值质量标准的添加（加速、更好的浏览器支持）
* 修复客观上不正确的行为

## RFD流程

### 1. 通过打开PR提出

[Fork仓库](https://github.com/agentclientprotocol/agent-client-protocol)并将 `docs/rfds/TEMPLATE.md` 复制到 `docs/rfds/my-feature.md`（使用kebab-case命名）。RFD可以从极简开始 - 只需一个电梯演讲和现状就足以开始对话。拉取请求成为讨论论坛，通过协作迭代完善想法。

### 2. 当有支持者时合并到"草稿"

如果核心团队成员决定支持，RFD提案将合并到"草稿"部分。支持者成为联系人，并将与作者合作使其成为现实。一旦进入草稿，就可以开始实现（正确使用RFD名称进行功能门控）。实现也可以在特定的SDK或代理/客户端级别开始，以在更广泛采用之前证明设计以获得更好的审查和反馈。

RFD是跟踪实现进度的动态文档。朝着RFC工作的PR通常会更新它以反映设计或方向的变化。

### 2b. 移动到"待删除"

从未落地的RFD可由核心团队成员自行决定关闭。以草稿形式落地的RFD改为移动到"待删除"，直到有时间将其从代码库中完全删除，然后完全删除。

### 3. 完全实现时移动到"预览"

当支持者认为RFD已准备好进行更广泛的审查时，他们打开PR将其移动到"预览"。这向社区发出提供反馈的信号。PR在支持者决定是否落地之前保持开放几天。

### 4. 已完成

一旦进入预览，RFD可以通过最终PR移动到"已完成"。核心团队应发表评论并表达关切，但\*\*最终决定始终由核心团队负责人做出"。根据RFD的内容，"已完成"是唯一可以表示单向门的状态（如果涉及稳定性承诺），因为在此之后更改可能需要对协议进行破坏性更改。

预览RFD不必完成。它们也可能回到草稿以等待进一步更改，甚至移动到"待删除"。

### 5. 实现和完成

#### RFD生命周期

* **早期草稿**：初始想法、头脑风暴、早期探索
* **成熟草稿**：格式良好的提案，准备进行更广泛的审查
* **已接受**：已批准实施，可能引用实施工作
* **待删除（尚未？）**：目前决定反对，但保留以供将来考虑
* **已完成**：实施完成并已合并

## 治理

项目目前有一个设计团队，[Zed团队作为负责人（BDFL）](../community/governance)。核心团队的支持者指导RFD完成流程，但最终决定权在团队负责人手中。这种结构在保持速度的同时预期未来的治理扩展。

## 讨论和审核

详细讨论通常在 [Zulip](https://agentclientprotocol.zulipchat.com/) 上进行，PR评论用于流程决策。详细讨论的结果应纳入相关RFD。RFD支持者通过在FAQ部分收集问题来积极策划讨论。如果PR讨论变得太长，应关闭它们，总结反馈，并重新打开并链接到原始内容。

## 许可

所有RFD均在Apache 2.0下许可。项目保持开源。

##