- https://mp.weixin.qq.com/s/VXKrdvO6EELR_IgxpKWmBQ # Ignis 核心设计理念 Ignis 的核心不是“让 agent 更会聊天”，而是把 agent 放回工程系统里：服务有边界，任务有状态，输出有 schema，依赖有图，运行时有隔离，平台有部署链路。 ## 1. Ignis 和 IgnisCloud 的分工 Ignis 负责开发者侧和框架侧，IgnisCloud 负责平台侧和运行时托管。前者定义怎么写、怎么构建、怎么描述服务；后者负责怎么发布、怎么部署、怎么激活、怎么在节点上跑起来。 ### Ignis 它提供 project/service 开发、Wasm HTTP service 构建、manifest 校验、SDK、运行时和 TaskPlan 框架能力。 ### IgnisCloud 平台侧实现，它负责项目、服务、版本、部署、节点激活、内部服务发现、agent 容器、对象存储、SQLite 备份、job/schedule 和计费等平台能力。 所以更准确的说法是：ignis 不是只给 agent 写 prompt 的工具，而是一个面向 agent 原生应用的服务平台底座。一个应用可以同时包含 frontend、Wasm HTTP service、agent service、异步 job、定时任务、SQLite 状态和内部服务调用。 ## 2. 为什么需要分布式多 agent 协作 单 agent 的上下文是有限的。当一个 agent 同时承担 plan、build、review、test、research 等多类工作时，很容易形成上下文污染。复杂任务更适合用分治法处理：把任务拆成多个子任务，让不同 agent 或 service 各自承担边界清晰的部分。 分布式不一定意味着多机多服务，也可以是单机多服务。重点不是“机器数量”，而是边界：agent、HTTP service、frontend、job、数据库和对象存储都应该是可组合的系统组件，而不是混在一个不可管理的对话里。 源码里的设计也体现了这一点：Ignis Service Link 使用同项目内的 service identity 和 `.svc` 内部地址，例如 `http://api.svc`；平台还保留了 `__ignis.svc` 作为内部系统服务，用来提供项目内服务发现。也就是说，agent 不需要自己扫描网络，HTTP service 可以通过平台接口拿到可用 agent 列表和 agent 描述，再把这些信息交给 coordinator。 ## 3. 核心模型：project、service、ignis.hcl `ignis.hcl` 是整个项目的中心配置。它描述 project、listeners、exposes、services、jobs 和 schedules。服务类型目前主要有三类：http、frontend、agent。 - **http service**：编译成 `wasm32-wasip2` 的 `wasi:http` 组件，由 ignis-runtime 加载并处理请求。 - **frontend service**：静态前端产物，通过 `frontend.build_command` 和 `output_dir` 发布，支持 SPA fallback。 - **agent service**：平台内置的 agent-service 容器，默认 Codex runtime，也支持 OpenCode runtime。 - **jobs 和 schedules**：把异步任务和 cron 调度纳入同一个 project manifest，job target 可以指向项目内 HTTP endpoint。 这套模型的价值在于：一个 agent 原生应用不只是“一个聊天机器人”。它可以是 web 前端 + API 服务 + 多个 agent + SQLite + 对象存储 + 后台 job + 定时任务。agent 是服务体系中的一等公民，而不是外挂。 ## 4. TaskPlan：把协作变成可执行的数据结构 `taskplan` crate 现在放在 ignis 仓库里，因为用户自己的 HTTP service 需要依赖它。IgnisCloud 负责托管 agent-service 运行时、容器、服务发现和 metadata；用户 HTTP service 负责存储 TaskPlan 状态、实现 callback、调度子计划和恢复父任务。 源码中的 TaskPlan 不是一句“帮我规划一下”的 prompt，而是明确的数据模型： - **TaskPlan**：包含 id、root_task_id、tasks、dependencies。 - **TaskSpec**：包含 id、agent_service、prompt、input、output_schema。 - **TaskDependency**：描述 from_task 到 to_task 的依赖关系。 - **OutputBinding**：用 JSON Pointer 把前置任务输出绑定到后置任务输入。 - **TaskState**：包含 queued、running、waiting_child_plan、succeeded、failed、cancelled。 `taskplan` crate 提供的能力也很工程化： - `validate_plan` 校验计划是否合法 - `ready_task_ids` 找出依赖已经完成、可以运行的任务 - `apply_output_bindings` 把上游输出写入下游输入 - `validate_task_output` 用 JSON Schema 校验 agent 的结构化结果 这意味着任务编排不依赖 agent 自己“记住刚才做了什么”。状态在数据库里，依赖在 TaskPlan 里，输出用 schema 验证，恢复和重试由执行器控制。 ## 5. agent-service 的真实执行模型 IgnisCloud 的 agent-service 是一个很薄的任务服务。它暴露 HTTP API 和 MCP 工具，收到任务后启动一次 agent runtime，让 Codex 或 OpenCode 通过工具领取任务、完成任务、提交结果。 ### 对业务 service 暴露的接口： - `POST /v1/tasks`：创建任务，返回 task_id。 - `GET /v1/tasks/{task_id}`：查询任务状态和结果。 - `GET /v1/metadata`：返回 runtime、memory 和 agent_description。 - `POST /mcp`：给 agent runtime 暴露工具。 ### 给 agent 的工具： 1. `get_task`：获取当前任务。 2. `submit_task`：提交最终 JSON 结果。 3. `spawn_task_plan`：创建子 TaskPlan。 注意，tool 的设计不是让 agent 自由调度所有事情，而是让 agent 通过受控接口和执行器协作。 `submit_task` 会用 `task_result_json_schema` 严格校验结果。如果 schema 校验失败，任务不会立刻失败，而是保持 running，让 agent 根据错误继续修正并重新提交。只有 callback 失败、runtime 超时或进程退出仍未成功提交时，任务才会进入 failed。 `spawn_task_plan` 只有在 task 创建时提供了 `tool_callback_url` 才能使用。调用成功后，当前任务会进入 `waiting_child_plan`，等待用户 HTTP service 的 TaskPlan executor 接管子计划、完成后再恢复父任务。 ## 6. 一个典型多 agent 工作流 假设一个应用有 web 前端、api 服务、orchestrator-agent、research-agent、reviewer-agent。工作流可以是： 1. 用户在 web 前端提交复杂需求。 2. api 服务创建初始任务，并调用 `__ignis.svc/v1/services` 获取同项目内 agent 列表。 3. api 过滤 `kind = agent` 的服务，拿到 service_url、runtime、memory、description，把它们作为 available_agents 交给 orchestrator-agent。 4. orchestrator-agent 判断需要拆分任务时，调用 `spawn_task_plan`，把子计划提交给 api 的 `tool_callback_url`。 5. api 作为 TaskPlan executor 校验子计划，记录状态，按依赖把任务分发给 research-agent、reviewer-agent 等内部 agent service。 6. 每个 agent 通过 `submit_task` 提交结构化 JSON，api 使用 taskplan 做输出校验和 output binding。 7. 子计划完成后，父任务恢复，orchestrator-agent 汇总最终结果，再由 api 返回给前端。 这个设计的关键点是：coordinator 负责判断和表达计划，executor 负责真正调度和记录状态。agent 不能随意改写已有计划，动态扩展通过 append-only child plan 完成，这样历史可审计，失败也能定位。 ## 7. 如何使用 先安装并登录，再创建 project，添加服务，构建、发布、部署。 ```bash curl --proto '=https' --tlsv1.2 -LsSf https://igniscloud.dev/i.sh | sh ignis login ignis project create hello-project cd hello-project ``` 添加一个 HTTP service 和一个 frontend service： ```bash ignis service new --service api --kind http --path services/api ignis service new --service web --kind frontend --path services/web ignis service check --service api ignis service build --service api ignis service publish --service api ignis service deploy --service api version ``` 添加一个 agent service。默认 runtime 是 Codex，也可以显式选择 OpenCode： ```bash ignis service new \ --service research-agent \ --kind agent \ --runtime opencode \ --path services/research-agent ``` agent service 需要在 `ignis.hcl` 里有 `agent_description`。这个描述会进入服务发现结果，也会被 coordinator 用来判断应该把哪类任务交给哪个 agent。 ## 8. 源码里的例子：Math Proof Lab `ignis/examples/math-proof-lab` 是一个很好的多 agent 示例。它不是泛泛地“解释定理”，而是把数学证明拆成不同专业职责： - **orchestrator-agent**：主控 agent，拆解任务并汇总 proof plan。 - **literature-agent**：检索论文、教材、课程资料和形式化库条目。 - **formal-verifier-agent**：与 Lean/Coq/Isabelle 等形式化系统交互，输出证明依赖树。 - **curriculum-agent**：判断目标受众的知识边界。 - **pedagogy-agent**：把证明翻译成目标受众能理解的自然语言。 - **rigor-critic-agent**：检查自然语言证明是否跳步、丢条件或不严密。 ## 9. 总结 IgnisCloud 解决的是另一半问题：control-plane 管理发布部署，node-agent 负责节点运行，agent-service 负责一次性 agent runtime，`__ignis.svc` 负责内部服务发现，`.svc` 负责同项目服务调用。这样，一个复杂的 agent native application 就可以由多个前端、多个后端、多个 agent 和多个平台能力组成。 TaskPlan 则是这套系统里最关键的协作结构。它把 agent 的计划从“上下文里的自然语言”变成“数据库里的可执行计划”。这也是多 agent 协作真正变得可管理、可重试、可验证、可审计的起点。 **GitHub**: [https://github.com/igniscloud/ignis](https://github.com/igniscloud/ignis)

- https://www.kimi.com/code/docs/kimi-code-cli/getting-started.html ``` # Linux / macOS curl -LsSf https://code.kimi.com/install.sh | bash ``` ``` # Windows (PowerShell) Invoke-RestMethod https://code.kimi.com/install.ps1 | Invoke-Expression ```