
一个非常有趣的矛盾:对开发者来说,默认打通权限是危险的;对普通人来说,默认隔离一切是麻烦的。同一件事,两群人的需求正好反过来。
春节期间,注意到一个叫 Taku 的产品。创始人 Austin 提到了一个非常有趣的观察:
对开发者来说,默认打通权限是危险的。 对普通人来说,默认隔离一切是麻烦的。 同一件事,两群人的需求正好反过来。
这个矛盾,恰恰揭示了当前 AI Agent 产品的一个核心痛点:我们缺少一个真正的 Agent OS。
模型提供推理能力,Harness 提供推理之外的一切。这句话来自 LangChain 的定义,而 ooderAgent 的场景组(Scene Group)设计,正是对这一理念的工程实践。本文将深入剖析 ooderAgent 的代码架构,探讨它如何试图解决这个"权限悖论"。
Claude Code 是为开发者设计的,它的逻辑是项目之间默认隔离。对开发者来说这完全合理:
// 开发者思维:隔离是安全
Project A → 独立的上下文、权限、配置
Project B → 独立的上下文、权限、配置
// 默认不互通,需要手动配置才能协作但普通人的需求正好相反:
// 普通人思维:协作是本能
"帮我分析一下这个股票"
→ 需要调用:量化选股器 + AI Hedge Fund + 知识图谱
→ 用户只想说一句话,让工具自己协作这个矛盾,就是 Agent OS 需要解决的核心问题。
今年 2 月,OpenAI 的 Codex 团队发了一篇文章,讲的是他们内部用 Codex agent 从零开始构建了一个百万行代码的产品。Martin Fowler 随后在 Thoughtworks 的专栏里跟进讨论,LangChain 写了「The Anatomy of an Agent Harness」,Salesforce 也出了自己的定义文章。
这些讨论里对 Harness 的共识大概是这样的:
Agent Harness 是包裹在 AI 模型外面的那一整层软件基础设施,负责管理模型的生命周期、上下文、工具调用、状态持久化和错误恢复。 模型是 CPU,上下文窗口是内存,Agent Harness 就是操作系统。
目前行业里讨论 Harness 的时候,主要关注的是怎么让单个 agent 更可靠地完成长时间、复杂的任务。但 ooderAgent 和 Taku 都往前走了一步:
多个生成物之间怎么协作?
ooderAgent 的场景组(Scene Group)是一个非常有意思的设计。让我们看看它的核心代码结构:

从代码结构来看,SceneGroup 是一个完整的协作空间,它管理着:
组件 | 职责 | 代码位置 |
|---|---|---|
Participants | 参与者管理(用户 + Agent) | SceneParticipantDTO.java |
Capabilities | 能力绑定与故障转移 | CapabilityBindingDTO.java |
Knowledge | 三层知识库绑定 | KnowledgeBindingDTO.java |
LLM Config | LLM配置与上下文管理 | LlmConfigService.java |
Workflow | 工作流生命周期管理 | SceneWorkflowService.java |
ooderAgent 的设计可以类比为 Taku 提出的三层 Harness:
ooderAgent 通过 YAML 格式的场景模板定义协作空间:
apiVersion: ooder/v1
kind: SceneTemplate
metadata:
id: daily-report
name: 日报汇报模板
participantMode: multi-user
spec:
skills:
- id: daily-collect
required: true
- id: report-generate
required: true
roles:
- name: MANAGER
description: 管理者,查看团队报告
- name: EMPLOYEE
description: 员工,提交日报
activationSteps:
MANAGER:
- step: 1
name: 配置日报模板
required: true
- step: 2
name: 邀请团队成员
required: true模板定义了场景的"蓝图",包括需要的能力、角色定义、激活步骤等。用户选择模板后,系统自动创建场景组实例。
这是 ooderAgent 最有意思的设计之一。一个能力可以有多个提供者,支持优先级和故障转移:
public class CapabilityBindingDTO {
private String capId; // 能力ID
private String capName; // 能力名称
private String providerType; // SKILL / AGENT
private String providerId; // 提供者ID
private int priority; // 优先级
private boolean fallback; // 是否启用故障转移
private String status; // ACTIVE / ERROR
}当主提供者失败时,系统自动切换到备用提供者。这解决了多Agent协作中的可靠性问题。
ooderAgent 实现了三层知识库绑定:
public enum KnowledgeLayer {
GENERAL, // 通用层:所有场景共享
PROFESSIONAL, // 专业层:特定领域共享
SCENE // 场景层:当前场景独享
}这意味着:
SceneGroupController 是场景组的 API 入口,它提供了完整的生命周期管理:
@RestController
@RequestMapping("/api/v1/scene-groups")
public class SceneGroupController {
// 创建场景组
@PostMapping
public ResultModel<SceneGroupDTO> create(@RequestBody CreateSceneGroupRequest request) {
SceneGroupDTO result = sceneGroupService.create(
request.getTemplateId(),
request.getConfig()
);
return ResultModel.success(result);
}
// 激活场景组 - 关键方法
@PostMapping("/{sceneGroupId}/activate")
public ResultModel<Boolean> activate(@PathVariable String sceneGroupId) {
// 1. 激活场景组
boolean result = sceneGroupService.activate(sceneGroupId);
// 2. 自动注册菜单(根据用户角色)
if (result) {
menuAutoRegisterService.registerMenusOnActivation(
sceneGroupId, templateId, userId, roleInScene
);
}
return ResultModel.success(result);
}
// 邀请成员 - 协作的核心
@PostMapping("/{sceneGroupId}/invite")
public ResultModel<Boolean> inviteMember(@PathVariable String sceneGroupId,
@RequestBody InviteMemberRequest request) {
// 创建邀请待办事项
todoService.createInvitationTodo(sceneGroupId, fromUserId, toUserId, role);
return ResultModel.success(true);
}
// 委派任务 - Agent间协作
@PostMapping("/{sceneGroupId}/delegate")
public ResultModel<Boolean> delegateTask(@PathVariable String sceneGroupId,
@RequestBody DelegateTaskRequest request) {
todoService.createDelegationTodo(sceneGroupId, fromUserId, toUserId, title, deadline);
return ResultModel.success(true);
}
}RoleManagementService 实现了基于角色的权限控制:
@Service
public class RoleManagementService {
private void initDefaultRoles() {
// 管理员角色
createRole("admin", "管理员", "系统运维、能力管理、用户管理", "ri-admin-line",
Arrays.asList(
"system:init", "system:config",
"capability:discover", "capability:install", "capability:distribute",
"scene:create", "scene:manage",
"user:manage", "org:manage",
"llm:config", "knowledge:manage"
));
// 普通用户角色
createRole("user", "普通用户", "场景参与、任务执行、业务流程", "ri-user-line",
Arrays.asList(
"scene:view", "scene:activate", "scene:participate",
"task:view", "task:execute", "task:submit",
"todo:view", "todo:process"
));
// 开发者角色
createRole("developer", "开发者", "能力开发、测试、发布", "ri-code-line",
Arrays.asList(
"capability:create", "capability:edit", "capability:test", "capability:publish"
));
}
}AgentChatController 实现了多Agent之间的消息传递:
@RestController
@RequestMapping("/api/v1/scene-groups/{sceneGroupId}/chat")
public class AgentChatController {
// 获取聊天上下文
@GetMapping("/context")
public ResponseEntity<Map<String, Object>> getChatContext(@PathVariable String sceneGroupId) {
SceneChatContextDTO context = chatService.getChatContext(sceneGroupId, userId);
return ResponseEntity.ok(result);
}
// 发送消息
@PostMapping("/messages")
public ResponseEntity<Map<String, Object>> sendMessage(
@PathVariable String sceneGroupId,
@RequestBody AgentChatMessageDTO message) {
String messageId = chatService.sendMessage(sceneGroupId, message);
return ResponseEntity.ok(result);
}
// 执行消息动作(如审批、委派等)
@PostMapping("/messages/{messageId}/action")
public ResponseEntity<Map<String, Object>> executeAction(
@PathVariable String sceneGroupId,
@PathVariable String messageId,
@RequestBody Map<String, Object> body) {
Object actionResult = chatService.executeMessageAction(
sceneGroupId, messageId, userId, actionId, actionData);
return ResponseEntity.ok(result);
}
// 待办事项管理
@PostMapping("/todos/{todoId}/accept")
public ResponseEntity<Map<String, Object>> acceptTodo(@PathVariable String todoId) {
boolean success = chatService.acceptTodo(userId, todoId);
return ResponseEntity.ok(result);
}
@PostMapping("/todos/{todoId}/delegate")
public ResponseEntity<Map<String, Object>> delegateTodo(
@PathVariable String todoId,
@RequestBody Map<String, Object> body) {
boolean success = chatService.delegateTodo(userId, todoId, toUserId);
return ResponseEntity.ok(result);
}
}当前市场上,Manus 和 Genspark 是两个备受关注的 Agent 产品。ooderAgent 的差异化在于:

ooderAgent 的核心优势在于:
特性 | Manus | Genspark | ooderAgent |
|---|---|---|---|
多Agent协作 | ❌ | ❌ | ✅ 场景组 |
跨应用记忆 | ❌ | ❌ | ✅ 三层知识库 |
能力故障转移 | ❌ | ❌ | ✅ 多提供者绑定 |
普通人友好 | ❌ | ✅ | ✅ 默认协作 |
开发者友好 | ✅ | ❌ | ✅ 精细化权限 |
ooderAgent 的场景组设计,本质上是在回答一个问题:如何让多个Agent围绕用户意图协作?
它通过三层架构给出了答案:
回到开头那个"有意思的矛盾":
ooderAgent 的解法是:默认协作,按需隔离。
场景组内,所有参与者和能力默认可以协作;但通过角色和权限系统,开发者仍然可以精细控制访问边界。这既满足了普通人的"一句话搞定"需求,又保留了开发者的安全诉求。
这正是 Agent OS 应该有的样子:模型提供推理能力,Harness 提供推理之外的一切——包括让多个Agent围绕用户意图协作的能力。
期待看到 ooderAgent 与 Manus、Genspark 在这个领域的更多探索。Agent OS 的时代,才刚刚开始。
参考资源: • ooderAgent 源码 • Taku 产品介绍:taku.ai • OpenAI Codex Harness • LangChain: The Anatomy of an Agent Harness
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。