架构
可用性：available
Mendry 在同一个 Go backend 内维护中立 Agent Harness，而不是另建 workflow service 或业务专用的第二套循环。仓库仍包含可独立构建的 backend、frontend 与 documentation package。
Harness 分层
Section titled “Harness 分层”| 层 | 负责内容 | 明确排除 |
|---|---|---|
agentcore/domain |
Event、Run、Tool、Invocation、Artifact、Profile、provider/executor/storage port | 不依赖事故、项目、账号、HTTP、数据库、Redis 或 provider SDK |
agentcore/application |
有界 Runner、模型 acceptance、配对 history、registry、policy、completion evaluator | 不负责凭据查询、传输、持久化实现或事故协议 |
| Adapter 与 composition | Provider 协议、MCP/tool client、凭据、持久化、event ingress、render/delivery | 不允许 event/model 数据替换可信 binding、effect、policy 或 completion code |
| 场景应用 | 事故证据门禁、lifecycle、checkpoint、review projection；未来非代码 workflow | 不拥有通用模型/工具 stepping |
Foundation 层已经实现并通过聚焦测试。具体 Local、Service 与 Product 交付仍有各自门禁。
共享执行流程
Section titled “共享执行流程”- Composition 选择可信 Profile、policy、provider、tools 与
RunStore。 - Runner 加载 durable run、配对 history、call 与 artifact。
- Profile 准备下一模型轮次；policy 筛选展示 catalog。
- 模型响应只有通过协议与工具校验后才会接受。
- 每次 dispatch 前再次执行 policy，并先持久化 invocation intent。
- 工具顺序执行，result 与 artifact batch 原子持久化。
- 工具 observation 返回配对 history，或执行 completion evaluation。
- Terminal、waiting、cancellation 与 budget reason 保持可检查。
- Foundation： 已实现的源码契约与共享机制。
- Local： 可运行且不依赖账号的源码 composition，支持持久文件 snapshot、检查、继续、操作员 resolution 与有界 MCP 示例；尚无受支持 binary 或兼容性保证。
- Service： 计划中的通用 event acceptance、PostgreSQL run store、claim、cancel 与 API。
- Product： 计划中的通用 run/call/artifact 视图。
- 事故应用： 现有项目/单登录账号应用，逐步复用 Foundation 机制。
这些模式共享边界，但并非都已发布。详见产品状态。
浏览器 console 与当前 Go API 仍服务事故应用。PostgreSQL 保存该应用的业务状态，Redis 保存可撤销登录 Session。签名 Webhook 创建项目范围 Observation，事故摄取对信号分组，remediation coordinator 负责证据门禁和审阅状态。
Remediation provider 调用已经经过共享 ModelStep，history 使用共享配对机制；但 coordinator 尚未由通用 Runner 替代。事故状态、工具路由、checkpoint、证据、预算与人工审阅语义仍归 remediation module 所有。该场景中的合并、部署、回滚与恢复结论继续由人控制。