openJiuwen 开源了 JiuwenSymbiosis，这东西到底能干嘛

这是一个让大模型直接控制机器人干活的开源框架。你用自然语言告诉机械臂"把黑色盒子放到白色盒子上面"，它就真的能去抓、去搬、去放。

不是仿真，是真机。

仓库在这：https://github.com/openJiuwen-ai/jiuwensymbiosis

---

为什么需要这个东西

搞过机器人的都知道，传统方式写一个抓放任务有多痛苦。你得处理运动学逆解、轨迹规划、视觉标定、碰撞检测……一个看似简单的"拿起来放下"，代码量动辄几百行，调试好几天。

更要命的是硬件碎片化。你给 SCARA 写的代码，换一台六轴机械臂基本得重来。不同品牌、不同构型，API 完全不兼容。

JiuwenSymbiosis 想解决的就是这个问题：让 LLM 来编排动作，框架来处理硬件差异和安全问题。

具体来说，它做了三件事：

第一，硬件解耦。 通过"能力织入"（Capability Mixin）的设计，一套代码能适配 SCARA、六轴、吸盘、夹爪这些不同构型。接入新硬件只需要写 YAML 配置和一个适配层，Agent 的核心逻辑不用动。

第二，安全兜底。 LLM 有时候会"幻觉"，输出类似 goto_xyzr(0, 0, -50) 这种指令，机械臂直接往桌子里撞。物理世界没有 Ctrl+Z，一次失误可能就把设备搞坏了。所以框架内置了三层安全护栏——运动前检查边界、异常后自动回零、每次动作后拍照验证。

第三，行为可审计。 工业场景最怕的就是不确定性。LLM 的自由编排很难复现，同样的话可能每次执行路径都不一样。框架用 SKILL.md 文档定义标准步骤，LLM 按文档走，不是随便发挥。

---

这东西在 openJiuwen 生态里的位置

JiuwenSymbiosis 不是凭空冒出来的，它是 openJiuwen 社区的一个子项目。openJiuwen 是华为搞的一个开源 Agent 平台，旗下有不少东西：

• agent-core（89星）：Python SDK，提供 Agent 运行时、异步IO、状态保存这些基础能力。JiuwenSymbiosis 就是直接建在这个上面的。安装就一行 pip install -U openjiuwen。
• agent-studio（73星）：可视化开发平台，拖拽式搭工作流，零代码/低代码那种。工作流画布是基于字节跳动的 FlowGram 项目做的。
• JiuwenSwarm（939星，最火的一个）：智能 AI 管家，能接微信、飞书这些平台。特点是能自主进化——你告诉它哪里做得不好，它会自动改进相关技能。
• DeepSearch（63星）：深度搜索引擎，做知识增强的检索和研究报告生成。支持片段级溯源，报告里的每个观点都能追溯到原始出处。
• agent-protocol（32星）：MCP 和 A2A 协议的 C++ SDK，解决智能体之间的通信问题。MCP 是 Model Context Protocol，A2A 是 Agent-to-Agent。

还有 agent-tools（工具生态）、agent-store（应用商店）、Relay（多Agent协作）这些。JiuwenSymbiosis 负责的就是把这套 Agent 能力延伸到物理世界。

---

核心特性拆开讲

1. 硬件适配怎么做

框架把机器人的能力拆成了一组 Mixin，每个 Mixin 声明一种能力：

• MotionMixin：笛卡尔空间运动（home、goto_xyzr、get_pose、get_home_pose）
• JointMotionMixin：关节空间运动（move_joint）
• ParallelGripperMixin：平行夹爪（open_gripper、close_gripper）
• SuctionMixin：吸盘（activate_suction、deactivate_suction）
• VisionMixin：视觉检测（get_grasp_info_simple、analyze_scene、pixel_to_base_xyz）

你要给一台新机器人写适配器，就组合需要的 Mixin，实现对应的抽象方法就行。比如 Piper 机械臂的实现：

class PiperApi(MotionMixin, JointMotionMixin, ParallelGripperMixin, VisionMixin, BaseRobotApi):
    def home(self): ...
    def goto_xyzr(self, x, y, z, r=None): ...
    def open_gripper(self, width_mm=80.0): ...
    def close_gripper(self, force_n=None): ...
    def get_grasp_info_simple(self, object_name): ...

如果是吸盘机器人，换成 SuctionMixin 就行，其他代码基本不变。

框架还会自动做能力过滤。每个 Mixin 声明了自己的 capability 字符串（比如 "motion.cartesian"、"grasp.parallel"），硬件环境也声明了自己支持的能力。取交集之后，只把两边都支持的工具暴露给 LLM。不会出现 LLM 调了一个硬件不支持的函数的情况。

工具发现的过程是这样的：build_robot_tools(api) 会扫描 API 类的 MRO（方法解析顺序），找到所有带 @robot_tool 装饰器的方法，自动生成 JSON Schema，然后包装成 openjiuwen 的 LocalFunction 工具。这个过程是自动的，不需要手动写 ToolCard。

还有一种统一入口模式 RobotControlTool：把所有动作封装到一个 robot_control 工具里，通过 action 和 params 两个字段派发。适合用 SKILL.md 走工作流式控制的场景，能缩短 LLM 看到的工具列表长度。

2. 三层安全护栏

这是我觉得这个框架最有价值的部分。

第一层：SafetyRail，运动前拦截。

每次调 goto_xyzr 或 goto_pose 之前，SafetyRail 的 before_tool_call 钩子会先执行。检查两件事：

1. Z 轴有没有低于安全下限（比如桌面高度 z=0）。低于就拒绝。
2. XY 有没有超出工作空间边界。超了也拒绝。

拒绝的方式是抛出 ValueError，openjiuwen 会把它转成一个 tool-exception 事件返回给 LLM。LLM 看到错误后会自己修正指令——比如它试了 z=-50 被拦了，下次可能改成 z=10。

有个细节：如果工具是通过 RobotControlTool 统一入口调用的（tool_name="robot_control"），SafetyRail 会先解包，从 tool_args 里取出真正的 action 和 params，再做检查。这样不管用哪种工具模式，安全检查都能生效。

class SafetyRail(AgentRail):
    def __init__(self, session, *, z_floor_mm=None, xy_bounds_mm=None):
        self.z_floor = z_floor_mm
        self.xy_bounds = xy_bounds_mm
        self.watch_tools = {"goto_xyzr", "goto_pose"}

    async def before_tool_call(self, ctx):
        # 解包 robot_control 派发
        if tool_name == "robot_control":
            action = args.get("action")
            params = args.get("params", {})
        
        # 安全检查
        if z < self.z_floor:
            raise ValueError(f"z={z} 低于安全下限 {self.z_floor}")

第二层：RecoveryRail，异常后恢复。

如果运动过程中出了异常（驱动断连、IK 求解失败等），RecoveryRail 的 on_tool_exception 钩子会被触发。它做两件事：

1. 释放末端执行器：尝试 deactivate_suction()（吸盘）或 open_gripper()（夹爪），哪个能调通就调哪个。
2. 回零：调 home() 把机械臂回到初始位姿。

每一步都是独立的 try-catch，释放失败不影响回零，回零失败不影响释放。目标是不管出了什么问题，机械臂至少回到一个已知的安全状态。

还有一个细节：RecoveryRail 只监控带 motion 或 grasp 标签的工具。视觉检测、诊断这些工具抛异常不会触发恢复——没必要因为检测失败就回零。

class RecoveryRail(AgentRail):
    async def on_tool_exception(self, ctx):
        # 释放末端
        for stop_method in ("deactivate_suction", "open_gripper"):
            fn = getattr(api, stop_method, None)
            if callable(fn):
                fn()
                break
        # 回零
        api.home()

第三层：VisualFeedbackRail，视觉验证。

每次运动或抓取动作执行完，VisualFeedbackRail 的 after_tool_call 钩子会：

1. 从 session.env.get_observation() 获取最新 RGB 帧
2. 编码为 base64 JPEG
3. 生成一条合成用户消息，包含图像和指令：“Frame captured after the previous action. Verify the action succeeded, then decide the next step.”
4. 注入到 Agent 的 ModelContext 里

这样 LLM 就能"看到"动作执行后的实际效果。比如抓取后，LLM 可以通过图像判断是否真的抓住了物体。如果没抓住，它可以决定重试或换个位置。

有个限制：每次 invoke 最多注入 max_frames_per_invoke（默认8）帧。这是为了防止长序列操作把 LLM 的上下文撑爆。视觉反馈是可选的，用纯文本模型时需要关掉（enable_visual_feedback=False）。

三个护栏都是可插拔的，可以根据需要开启或关闭。

3. 视觉闭环

视觉感知被做成了一个独立的 Sidecar 进程，基于 GroundingDINO + SAM2，通过 FastAPI 提供 HTTP 接口。

为什么用 GroundingDINO + SAM2？

GroundingDINO（IDEA-Research，Apache-2.0 许可）做开放词汇的文本→框检测。你给它一句话"black box"，它能在图像里找到对应的物体框。SAM2（Meta，Apache-2.0 许可）做精确分割，把框变成高质量的 mask。

选择这个组合而不是直接用 VLM（比如 Qwen3-VL）的原因是：VLM 会把 tool_call 塞进 reasoning_content 里，导致不调工具。而且 GroundingDINO + SAM2 的检测精度更高，延迟更低。

Sidecar 进程的接口：

POST /segment  {image_base64, text_prompt}
  -> {results: [ {mask_base64, shape, box, score, label}, ... ]}

服务启动时会从 HuggingFace 下载模型权重（首次可能要几分钟），之后就是本地推理了。

LLM 怎么用视觉？

LLM 不需要理解像素坐标、相机内参这些东西。它只需要调 get_grasp_info_simple(object_name="黑盒子")，框架内部自动完成：

1. 从腕部相机（RealSense）拍照
2. 把图像 base64 编码发给 Sidecar
3. Sidecar 用 GroundingDINO 检测目标位置（像素坐标）
4. Sidecar 用 SAM2 做精确分割，取 mask 的质心
5. 通过深度图获取质心的深度值
6. 通过标定矩阵反投影到机器人基座坐标系：T_base_cam = T_base_flange(当前末端位姿) × T_flange_cam(标定常量)
7. 考虑物体高度、桌面位置、工具偏移，算出安全的抓取高度

返回的结果是这样的：

{
  "ok": true,
  "position": [300, 50, 180],       // 物体顶面中心（仅取 x, y）
  "grasp_z": 105,                    // ★ 安全夹取高度（直接用）
  "grasp_position": [300, 50, 105],  // = goto_xyzr 的目标
  "bottom_z": 80,                    // 物体底面（叠放用）
  "height_mm": 100,                  // 物体高度
  "score": 0.85,                     // 检测置信度
  "pixel_uv": [320, 240],            // 像素坐标
  "depth_m": 0.20                    // 深度值
}

其中 grasp_z 是框架算好的安全夹取高度，直接用就行。文档里反复强调不要自己拿 position 的 z 去加减——这是最容易踩的坑。grasp_z 已经考虑了抓取深度偏移（grasp_z_offset_mm，默认 -25mm，表示在顶面下方 25mm 处夹盒身）和桌面安全余量。

标定文件（piper_calib.json）：

这个文件包含三个东西：

1. T_flange_cam：法兰到相机的 4x4 变换矩阵（手眼标定结果）
2. camera_intrinsics：相机内参（fx, fy, cx, cy）
3. object_anchors：物体锚点坐标（可选，用于辅助检测）

4. SKILL.md 技能文档

这是框架用来约束 LLM 行为的机制。用 Markdown 写清楚每个操作的标准步骤，LLM 按步骤执行。

为什么不用自由编排？

LLM 的自由编排有两个问题：

1. 不可复现——同样的话可能每次执行路径不同
2. 容易出错——LLM 可能跳过关键步骤（比如忘记先回零就直接移动）

SKILL.md 通过结构化的步骤定义解决了这两个问题。

visual_pick（视觉抓取）：

触发条件：用户指令含抓取意图 + 机器人有运动+视觉+抓取能力 + 夹具空载。

标准步骤：

步骤	动作	参数	目的
1	home	{}	回到拍照位姿，给视觉一个稳定的深度基线
2	<释放>	{}	确保夹具空载（夹爪张开/吸盘未吸）
3	get_grasp_info_simple	{"object_name": "黑盒子"}	检测目标，获取 grasp_z
4	goto_xyzr	{x, y, grasp_z + 50}	移到目标正上方（approach hover）
5	goto_xyzr	{x, y, grasp_z}	下降到夹取高度
6	<抓取>	{}	闭合夹爪 / 开启吸盘
7	goto_xyzr	{x, y, grasp_z + 80}	提起到搬运高度（lift）

其中 <抓取> 和 <释放> 是抽象动作，框架会根据机器人能力自动映射：

• 有 grasp.parallel 能力 → <抓取> = close_gripper，<释放> = open_gripper
• 有 grasp.suction 能力 → <抓取> = activate_suction，<释放> = deactivate_suction

腕部相机的一个坑：相机装在机械臂腕部（eye-in-hand），一旦移动就可能被遮挡或视角改变。所以如果任务既需要抓取又需要放置，必须在 home 处一次性把"要抓的物体"和"放置目标"两个坐标都读好存下来，再开始移动。否则抓取后相机就拍不到放置目标了。

visual_place（视觉引导放置）：

触发条件：用户指令含放置意图 + 前置条件：夹具已抓住目标物体。

标准步骤：

步骤	动作	参数	目的
1	goto_xyzr	{px, py, place_z + 80}	横移到放置点上方
2	goto_xyzr	{px, py, place_z}	下降到放置高度
3	<释放>	{}	释放物体
4	goto_xyzr	{px, py, place_z + 80}	提起，避免拖动物体
5	home	{}	回零

失败处理（放置比抓取风险更高，因为物体已经悬空）：

• 识别失败（get_grasp_info_simple 返回 score 太低）→ 不要强行释放，交还上层
• goto 越界 → 不要原地释放，先抬回搬运高度再 home
• 释放报错 → 抬开距离再 home，不要重试释放（防止双重释放——如果第一次其实成功了，再调一次可能会释放掉别的东西）
• 提起/home 失败 → 再试一次 home，仍失败就上报"需手动复位"

slot_pick（批量循环抓放）：

适用场景：同一类物体一个一个抓完。比如"把传送带上的零件逐个放到料箱里"。

这个技能内部封装了循环逻辑：检测→抓取→放置→再检测，直到检测不到要抓的物体（或达到最大循环次数）。LLM 只需要调一次 slot_pick 工具，不需要自己写循环。

返回值里 stage 字段告诉 LLM 循环是怎么结束的：

• done_no_chip：检测不到要抓的物体了（正常结束）
• done_no_slot：检测不到放置目标了
• done_max_cycles：达到最大循环次数

---

源码结构

项目总共 66 个文件，按四层架构组织：

jiuwensymbiosis/
├── env/                  # Layer 2: 硬件抽象层
│   ├── base.py           # BaseRobotEnv 基类 + RobotObservation 数据类
│   └── mock.py           # MockArmEnv 无硬件模拟环境
│
├── api/                  # Layer 3: 能力层
│   ├── base.py           # BaseRobotApi：持有 env 引用
│   ├── decorators.py     # @robot_tool 装饰器 + JSON-Schema 自动生成
│   └── mixins.py         # 能力 Mixin（Motion/Suction/ParallelGripper/Vision）
│
├── adapters/             # Layer 1: 硬件适配器
│   ├── _common/          # 通用组件：标定、相机、检测客户端、几何变换、安全
│   └── piper/            # Piper 6-DoF 机械臂适配
│       ├── lowlevel.py   # 底层 CAN 驱动（piper_sdk 封装）
│       ├── env.py        # PiperEnv：BaseRobotEnv 的 Piper 实现
│       ├── api.py        # PiperApi：组合 Motion+Gripper+Vision 的完整 API
│       ├── geometry.py   # SE(3) 几何 + 针孔相机模型 + 眼在手上投影
│       ├── session.py    # build_piper_session：从 YAML 构建完整会话
│       └── slot_pick.py  # Piper 的槽位抓取实现
│
├── agent/                # Layer 4: Agent 核心
│   ├── abstractions.py   # 从 openjiuwen 重导出的类型（AgentRail, Tool, ToolCard...）
│   ├── builder.py        # build_robot_agent 工厂函数
│   ├── config.py         # ModelSpec, RobotAgentConfig, ROBOT_PROMPT_TEMPLATE
│   └── session.py        # RobotSession：持有 env + api + sidecars
│
├── rails/                # 安全护栏
│   ├── safety.py         # SafetyRail：运动前边界检查
│   ├── recovery.py       # RecoveryRail：异常后自动回零+释放
│   └── visual_feedback.py # VisualFeedbackRail：运动后注入相机帧
│
├── tools/                # 工具层
│   ├── builder.py        # build_robot_tools：扫描 @robot_tool → LocalFunction
│   ├── robot_control_tool.py # RobotControlTool：统一入口 + action 派发
│   └── slot_pick/        # 槽位抓取（检测、策略、VLM判定）
│
├── skills/               # 技能文档
│   ├── visual_pick/SKILL.md
│   ├── visual_place/SKILL.md
│   └── slot_pick/SKILL.md
│
├── serving/              # 视觉服务
│   └── grounding_dino_sam2_server.py  # GroundingDINO + SAM2 的 FastAPI 服务
│
└── utils/
    └── proxy.py          # clear_proxy_env() 清理代理环境变量

核心数据流：

用户: "把黑色盒子放到白色盒子上面"
  │
  ▼
LLM 解析意图，读取 SKILL.md，规划步骤
  │
  ▼ tool_call: robot_control(action="home", params={})
RobotControlTool 解包 action
  │
  ▼
SafetyRail 检查边界 → 不通过则拒绝，LLM 自行修正
  │
  ▼ 通过
@robot_tool 方法执行硬件操作（通过 env 驱动真实硬件）
  │
  ▼
VisualFeedbackRail 注入相机帧到 LLM 上下文
  │
  ▼ 异常时
RecoveryRail 自动回零 + 释放末端

---

配置文件

配置用 YAML 写，以 configs/piper/pick_box.yaml 为例，分三大块：

机械臂参数（env.cfg.low_level）

can_port: "can_left"           # CAN 总线接口名，用 ip link show 查看
move_speed: 20                 # 运动速度，真机建议先设慢点（20），跑通了再提
tool_offset_mm: 95.0           # 法兰到指尖的距离（mm），必须实测
z_correction_mm: -57.0         # Z 轴检测值校正，负值=下拉
grasp_z_offset_mm: -25.0       # 抓取深度偏移，顶面下方 25mm 夹盒身
chip_thickness_mm: 75.0        # 物体底面到指尖距离，叠放时用
calib_path: "piper_calib.json" # 标定文件路径
home_lift_mm: 250.0            # 回零抬起高度
z_safe_margin_mm: -10.0        # Z 安全余量
home_use_init_pose: true       # 用操作者摆放的位姿作为 home
gripper_open_mm: 90.0          # 夹爪张开宽度，必须能罩住目标
gripper_effort: 1000           # 夹持力（0.001 N·m 单位，1000 = 1 N·m）
gripper_settle_s: 0.8          # 夹爪稳定时间（秒）
camera_serial: "349622073363"  # RealSense 序列号
camera_resolution: [640, 480]
camera_fps: 30

几个容易踩坑的配置：

• tool_offset_mm：这个值影响所有坐标计算。如果设错了，机械臂会偏移一个固定距离。必须实测，不能凭感觉填。
• z_correction_mm：GroundingDINO + SAM2 检测出来的物体高度通常会偏高（大约高估 57mm），需要负值下拉修正。这个值需要在真机上标定。
• grasp_z_offset_mm：-25mm 表示在物体顶面下方 25mm 处夹取。如果你的夹爪比较短，可能需要调小。
• home_use_init_pose：设为 true 时，home 位姿就是启动时操作者手动摆放的位姿。监视模式（watch_pick_place）常用这个。

视觉服务（api_servers）

api_servers:
  - _target_: jiuwen_robotics.serving.grounding_dino_sam2_server.main
    device: cuda
    port: 8114
    host: 127.0.0.1
    gdino_model_id: "/xxx/IDEA-Research/grounding-dino-base"
    sam2_model_id: "/xxx/facebook/sam2.1-hiera-large"
    box_threshold: 0.35    # 检测框置信度阈值，太高漏检，太低误检
    text_threshold: 0.25   # 文本匹配阈值
    use_sam2: true         # false 的话只用 GroundingDINO，框的中心作为检测点

模型选择：

• GroundingDINO 默认用 IDEA-Research/grounding-dino-base（Swin-B），不是 Tiny 版。精度更高但更慢。
• SAM2 默认用 facebook/sam2.1-hiera-large，分割质量最好。
• 首次运行会从 HuggingFace 下载权重，可能要几分钟。

LLM 配置（model）

model:
  provider: OpenAI
  api_base: "your own api"
  api_key: ""
  model_name: "deepseek-ai/DeepSeek-V3.2"
  temperature: 0.3
  max_tokens: 2048

推荐用 DeepSeek-V3.2。文档里提到 Qwen3-VL 会把 tool_call 塞进 reasoning_content 导致不调工具，所以不推荐用 VLM 作为编排 LLM。视觉由 GroundingDINO + SAM2 负责，编排 LLM 只需要支持工具调用就行。

---

怎么用

安装

# 创建环境
conda create -n jiuwensymbiosis python=3.11
conda activate jiuwensymbiosis

# 克隆仓库
git clone https://github.com/openJiuwen-ai/jiuwensymbiosis.git
cd jiuwensymbiosis

# 安装依赖
pip install -r requirements.txt

# 真机需要额外装（手动安装）
pip install piper_sdk==0.6.1

注意 requirements.txt 里有 torch==2.8.0+cu128，会从 PyTorch 的 CUDA 12.8 索引下载。如果你的 CUDA 版本不同，可能需要调整。

无硬件干跑

# 把项目路径加到 PYTHONPATH
export PYTHONPATH=/path/to/jiuwensymbiosis

# --mock 使用 MockArmEnv，不需要真机
python examples/piper_pick_demo.py \
    --config configs/piper/pick_box.yaml \
    --mock

MockArmEnv 是一个模拟的四轴机械臂，内存里跟踪位姿，返回假的 RGB 图像（灰色背景中间一个白点）。能跑通整个 Agent 流程，但视觉检测会返回模拟值。

真机运行

# 1. 先激活 CAN 总线（需要 sudo）
sudo ip link set can_left type can bitrate 1000000
sudo ip link set can_left up

# 2. 启动视觉检测服务（另一个终端）
python -m jiuwensymbiosis.serving.grounding_dino_sam2_server \
    --host 127.0.0.1 --port 8114 \
    --gdino-model-id /path/to/grounding-dino-base \
    --sam2-model-id /path/to/sam2.1-hiera-large

# 3. 运行 demo
python examples/piper_pick_demo.py \
    --config configs/piper/pick_box.yaml \
    --max-iter 30 \
    --api-key "your-api-key"

Python API 方式

import asyncio
from jiuwensymbiosis.utils.proxy import clear_proxy_env
clear_proxy_env()  # 必须在 import openjiuwen 之前，清理代理环境变量

from jiuwensymbiosis import build_robot_agent
from jiuwensymbiosis.agent import RobotAgentConfig, ModelSpec
from jiuwensymbiosis.adapters.piper import build_piper_session

session = build_piper_session.from_yaml("configs/piper/pick_box.yaml")
config = RobotAgentConfig(
    mode="hybrid",                    # tool/code/hybrid 三种模式
    model_spec=ModelSpec(
        provider="OpenAI",
        api_base="https://api.siliconflow.cn/v1",
        api_key="your-api-key",
        model_name="deepseek-ai/DeepSeek-V3.2",
    ),
    enable_skill=True,                # 启用 SKILL.md 技能
    enable_visual_feedback=False,     # 纯文本模型时关闭视觉反馈
    max_iterations=30,                # 最大迭代次数，防止死循环
)

with session:  # context manager，自动 connect/disconnect
    agent = build_robot_agent(session, config=config)
    result = asyncio.run(agent.invoke({
        "query": "把黑色盒子放到白色盒子上面。",
        "conversation_id": "pick-box-001",
    }))
    print(result)

批量抓放模式

# 常驻监视：黑盒放到白盒上，完成后持续观测
# 把黑盒从白盒上移走，它会自动再抓一次
python examples/piper_watch_pick_place.py \
    --config configs/piper/watch_pick_box.yaml

这个模式不经过 LLM，是一个纯控制循环。配置里的 slot_pick 段定义了要抓什么、放哪里：

slot_pick:
  chip_object_name: "black box"
  slot_object_name: "white box"
  place_done_radius_mm: 60.0    # 判定"已放上"的距离阈值
  chip_pick_z_offset_mm: -25.0
  chip_thickness_mm: 75.0

---

环境要求

项目	要求
系统	Ubuntu 22.04（已验证）
Python	>= 3.11
GPU	CUDA（GroundingDINO + SAM2 需要）
硬件	Piper 6-DoF 机械臂 + RealSense 深度相机（或 --mock）

主要 Python 依赖：

• openjiuwen==0.1.13：agent-core SDK
• torch==2.8.0+cu128：PyTorch CUDA 版
• transformers==5.7.0：HuggingFace，加载 GroundingDINO
• pyrealsense2==2.57.7.10387：RealSense 相机驱动
• scipy==1.17.1：用于 SE(3) 旋转矩阵计算
• fastapi + uvicorn：视觉检测服务框架

---

和 ROS 这些比起来怎么样

说实话，JiuwenSymbiosis 和 ROS2 + MoveIt 不是同一个赛道的东西。

ROS 是通用机器人开发框架，功能更全但也更重。你要写 URDF、配 TF 树、写 action server/client、处理消息类型转换……入门门槛高得多。JiuwenSymbiosis 的优势在于 LLM 原生集成和低门槛——YAML 配置加自然语言就能跑起来，不需要懂运动学。

和 NVIDIA Isaac Sim 比，Isaac Sim 强在仿真，可以先在虚拟环境里验证再部署到真机。JiuwenSymbiosis 目前没有仿真支持（mock 模式只是简单的内存模拟），但它的安全护栏设计更适合直接上真机。

和 Hugging Face 的 LeRobot 比，LeRobot 更偏研究（模仿学习、强化学习），JiuwenSymbiosis 更偏工程落地（LLM 编排 + 安全护栏 + 技能文档）。

总的来说，如果你的场景是"用自然语言控制真实机器人做抓放任务"，JiuwenSymbiosis 目前可能是门槛最低的开源方案。

---

怎么参与贡献

1. 先签 CLA：https://clasign.osinfra.cn/sign/68ee0908765718ad08bab9ee
2. Fork 仓库，建分支开发
3. 提 PR，提交信息用英文的 Conventional Commits 格式（feat: xxx、fix: xxx 这种）

项目目前还比较新（6月12号开源的，3个星），社区还在早期阶段，现在参与进去应该能有不少交流机会。

---

接下来可能的发展方向

从社区的其他项目来看，有几个方向是可以预期的：

• 接入更多机器人品牌（目前只有 Piper 的适配器，但架构是通用的）
• 多机器人协作（agent-protocol 已经提供了 MCP/A2A 通信基础）
• 和 agent-studio 集成（可视化配置机器人工作流）
• 引入仿真环境（和 Isaac Sim 或 MuJoCo 对接）

不过这些都还没看到具体的 roadmap，只是从生态布局推测的。

---

相关链接：

• GitHub：https://github.com/openJiuwen-ai/jiuwensymbiosis
• openJiuwen 官网：https://www.openjiuwen.com
• 文档中心：https://github.com/openJiuwen-ai/docs
• 社区治理：https://github.com/openJiuwen-ai/community