核心概念

假设一个小团队正在准备发布公告。人先定目标，Agent 起草文件，另一位成员评审，最后还要确保 Markdown 文件随时找得到。Rudder 给这条工作链上的每个环节安排了明确位置。

​

一件任务如何穿过 Rudder

组织是团队的工作空间，组织目标说明这次发布为什么重要。项目可以把公告和同一次发布的其他任务、资料及日期放在一起。 负责人可以先在 Chat 中提出要求，通过对话逐步修改公告。如果工作需要明确负责人、跟踪依赖、显示状态或安排评审，就使用 Issue。 Agent 是长期承担某类职责的团队成员。Agent 运行是这个 Agent 的一次有边界执行。运行环境才是 Rudder 为这次执行调用的工具或服务。三者彼此相关，但不是一回事。 一次运行会留下摘要和对话记录等证据。写好的公告作为产物留在 Chat 或 Issue 旁边。评审结论也回到同一条工作记录，团队因此能看见哪些内容已被接受、哪些内容还要改。

​

常用入口各自解决什么问题

Overview 汇总组织近况，让负责人看到工作在哪里推进、在哪里等待。它只是入口，不替代原始 Chat、Issue、运行记录、评审或审批。

​

什么时候值得增加结构

Rudder 不要求每件事都用上所有对象。一轮短文案修改可以一直留在 Chat。涉及多项依赖和独立评审人的发布工作，更适合拆成一个或多个 Issue。多件工作共享结果或资料时，再建立项目。只有触发条件和结果去向已经稳定时，才值得使用自动化。 判断标准很简单：保留足够的信息，让下一步和最终结果都能被检查；工作不需要的字段和对象，不必为了完整而创建。

​

建议阅读顺序

这条路径不依赖侧边栏顺序：

1. 创建第一个组织，完成一件小任务。
2. 选择 Chat 或 Issue，确定适合自己的推进方式。
3. 理解 Agent 和 Agent 运行，分清运行环境的边界。
4. 需要明确协作时，按任务生命周期从接收推进到完成。
5. 评审 Agent 工作，把结果、证据和结论留在一起。