设计企业AGENT

Prompt

--- ## Claude Tag Claude Tag 不是简单的“Slack Bot + Claude API”。从 Anthropic 目前公开的资料看，它更接近一个 **面向团队共享空间的托管 Agent Runtime / Harness**，核心抽象可以概括成： ```text Slack Channel / Thread │ ▼ Trigger & Context Intake │ ▼ Durable Session / Thread State │ ▼ Claude Agent Harness │ ├── Checklist / planning / tool loop ├── Skills / plugins / standing instructions ├── Channel & workspace memory └── Routines / proactive participation │ ▼ Ephemeral Sandbox (one per active thread/session) │ ▼ Agent Proxy ── credential injection ──► GitHub / Warehouse / SaaS / HTTP APIs │ ▼ Slack thread / PR / artifact / chart / hosted page ``` 真正关键的设计不是 prompt，而是下面这些 harness primitives： 1. **Thread = durable task/session boundary**：一个 Slack thread 对应一个工作 session；sandbox 可以释放再重建，但 thread 和外部产物持续存在。 2. **Sandbox = hands**：Claude 在 Anthropic 托管的隔离环境里读写文件、运行代码、clone repo、生成图表和 artifact。 3. **Agent Identity = team-level principal**：频道任务不冒充发起人，而以 Claude 自己的 service account 身份访问 GitHub、数据仓库等系统。 4. **Agent Proxy = capability + credential boundary**：密钥不进 sandbox，出站请求在 proxy 处按规则放行，并在边界处注入 credential。 5. **Scope = permission/memory boundary**：组织、workspace、private channel 构成访问和记忆的作用域；同一频道里的所有人共享同一套 agent capability。 6. **Memory != transcript**：长期记忆是经过整理的 notes；公共频道记忆可进入 workspace memory，私密频道有独立 store。 7. **Routine = durable trigger**：任务可由 @mention、定时任务、channel watch、PR/repository event 等触发。 8. **Ambient participation = trigger policy**：Claude 可结合频道上下文、记忆和 standing instructions 判断是否主动插话；@mention 是“保证响应”，而不一定是唯一入口。 9. **Skills = procedural policy layer**：业务方法、数据语义、runbook、分析规范通过 Markdown/文件形式动态装载，而不是全部硬编码到系统 prompt。 10. **Harness deliberately stays replaceable**：Anthropic 多篇工程文章反复强调，模型能力变化快，harness 只应保留稳定接口和组合原语，避免把短期模型缺陷永久写死。 如果要复刻一个“Claude Tag-like”系统，最重要的不是先实现 Slack UI，而是先建立 **session / sandbox / identity / proxy / memory / trigger / skill / audit** 这八个边界。 --- --- ## 0. Grok Bot Grok Bot 更接近一种**岗位型、持续存在、消息驱动的多 Agent 组织**，而不是「中央调度器 + 固定专家池」。 它的关键设计不是把模型能力切碎，而是把下面几件事分开： - **角色 / ownership**：谁长期负责结果； - **协作 / handoff**：任务如何在 Bot 之间流转； - **上下文 / memory**：哪些背景长期跟随哪个 Bot； - **执行 / harness**：具体任务由哪个执行环境完成； - **授权 / governance**：哪些外部动作允许真正发生。 核心原则可以概括为： > **协作可以动态，责任必须清楚；能力可以通用，上下文应有边界；规划可以开放，外部承诺必须受控。** --- # 1. 外部 Harness 总体结构 下面的图刻意采用与 `codex_internal_harness.txt` 相似的「结构化文本图」表达方式。 `codex_internal_harness.txt` 描述的是单个 Agent **内部**怎样从 conversation log、task state、filesystem、TODO、tool state、constraints、memory 中选择当前 context，再送给 LLM。 这里则向外扩一层：研究 **Bot 与 Bot 之间**、**Bot 与执行器之间**、以及**整个 Agent 系统之外的安全与资源边界**。 ```text 用户指令 / Routine / 外部事件 / Bot 消息 │ ▼ ┌─ wake-up / continuation ├─ async Bot-to-Bot messaging ├─ project group chat 协作运行 Harness ─┼─ owner / handoff / status ├─ user interruption / reprioritization └─ visible artifacts / results │ ▼ 当前需要负责的 Bot │ ┌────────┼────────┐ │ │ │ ▼ ▼ ▼ 协调 Bot 职责 Bot A 职责 Bot B ... 〔可选〕 ↔ ↔ │ │ │ └────────┼────────┘ │ role / conversation / memory / routines │ ▼ proposed tool / action │ ▼ Auto Review / approval ┌──────────┼──────────┐ │ │ │ ▼ ▼ ▼ allow ask human deny │ │ └──────┬───┘ ▼ 获准执行入口 │ ┌─────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ 共享云电脑 Connectors delegated harness browser plugins/MCP e.g. Cursor shell backend creds Cloud Agent files │ │ │ │ └─────────┼────────────────────┘ ▼ 外部系统 / repo / SaaS │ ▼ result / evidence │ └──────────────→ 回传原 Bot / 项目群 ──────────────────────────────────────────────── 外围强制边界 ├─ user-level Firecracker microVM ├─ source-system identity & permissions ├─ network controls ├─ enterprise policies ├─ local-execution controls ├─ audit / action recording / telemetry └─ downstream harness's own controls ``` 这张图表达的是**逻辑责任和控制边界**，不是已公开的服务部署拓扑。 尤其不应从图中推断： - 所有消息都经过一个隐藏中央 Orchestrator； - Grok Bot 底层存在统一全局 DAG； - 所有外部副作用都必经 Auto Review； - Bot 之间已经实现严格的权限隔离； - 所有父级授权都会自动、完整地递归传给子 Agent。 --- --- ┌─ conversation log │ Agent runtime ───┼─ structured task state ├─ filesystem / git ├─ TODO / goal graph ├─ tool state ├─ decisions / constraints └─ episodic memory │ ↓ deterministic selector │ ↓ 当前所需 context │ ↓ LLM --- 请分析以上harness设计，从第一性原理出发，结合LLM的本质，设计通用的企业Agent最佳架构，给出详细设计方案。 期望： 1.能够通过各种通讯软件联系公司员工 2.天然多并发，多实例上下文不串通 3.天然多角色，不同业务任务隔离 4.组件/功能自适应，能够兼容各类企业环境 注意：所有要求与所给信息都不一定正确/最佳，请自行思考。 参考文档： 1. **Omnichannel**：员工可以从任意企业通讯工具访问 Agent。 2. **Identity Native**：所有 Agent 行为绑定真实企业身份。 3. **Massively Concurrent**：水平扩展，不依赖单机状态。 4. **Context Isolated**：Tenant/User/Role/Task/Session 全层级隔离。 5. **Multi-role Native**：Role 是第一等架构对象。 6. **Capability Scoped**：Agent 能力由显式 Capability 决定。 7. **Workflow Native**：支持长任务、Retry、Timer、Human Approval。 8. **Secure by Construction**：Secret、权限、数据访问不依赖 Prompt。 9. **Auditable**：所有 Run 和 Side Effect 全链路可追踪。 10. **Recoverable**：任务崩溃、模型失败、部署升级都可恢复。 11. **Model Agnostic**：Agent 与具体模型解耦。 12. **Continuously Evaluable**：Agent 的每次改变都可以量化评估和回滚。