# Monoco Issue System: 智能体时代的协作基石

## 1. 为什么需要 Issue？

在软件工程中，**熵 (Entropy)** 是永恒的敌人。随着代码库的增长，系统的复杂度呈指数级上升。

**Issue (工单/事项)** 的发明，是为了对抗这种熵增。它不仅仅是一个“待办事项”，它是：

- **最小价值单元**: 定义了“我们为什么要做这件事” (Why & What)。
- **责任边界**: 明确了“这件事何时开始，何时结束，谁负责” (Who & When)。
- **契约**: 是产品经理、架构师与开发者之间达成的一致性协议。

没有 Issue，开发就是混乱的堆砌；有了 Issue，开发通过一系列确定的“原子提交”构建宏伟的大厦。

## 2. 为什么 Agent 协作更需要 Issue？

如果说人类工程师需要 Issue 来协作，那么 **AI Agent (智能体)** 对 Issue 的需求则是**致命的**。

### Agent 的三大阿喀琉斯之踵

1.  **幻觉 (Hallucination)**: 如果上下文模糊，Agent 会自行脑补，产生错误的假设。
2.  **失忆 (Amnesia)**: Agent 没有长时记忆。如果没有持久化的状态记录，它在多轮对话后会迷失目标。
3.  **发散 (Divergence)**: 如果没有严格的轨道，Agent 的行为会不可预测地偏离初衷。

### Monoco 的解决方案：Issue as Code

Monoco 重新发明了 Issue 系统，专门用于解决人机协作的挑战。我们将 Issue 视为 **“锚 (Anchor)”**：

- **结构化上下文**: 通过 Markdown Front Matter 和 Body，为 Agent 提供无歧义的输入。
- **持久化状态机**: 将 Agent 的行为状态（Doing, Review, Done）固化在文件系统中。
- **确定性校验**: 使用 Linter 像检查代码一样检查任务定义，拒绝模糊的指令。

在 Monoco 中，**Issue 是你与 Agent 对话的唯一凭证**。不要在聊天框里布置长期的任务，把它写成 Issue。

---

**下一章**: [01. 构造: 通用原子](./01_structure.md)
