openYuanrong Agent 方向真实案例验证

lqj_本人2026-03-16 16:07

一、写在前面

这篇文档是一次实际搭建和验证过程的整理。目标很明确：基于 openYuanrong 做一个可运行的 Agent Web 应用，然后用这个应用去验证下面五项能力是否能落到真实调用链路上。

需要验证的五个方向如下：

  1. Session 亲和调度，支持 Agent 多轮会话
  2. Session 抽象、Session 自动管理和高性能 Session 对象共享
  3. 安全沙箱调度能力以及 Sandbox API
  4. 原生分布式 wait/notify API，支持 Agent 吞吐提升 30%
  5. Session 迁移与弹性，支持高负载向低负载迁移

二、项目范围与目录

本次使用到的目录有两个：

  • real-agent-openyuanrong
    • Web 应用本体
    • 提供页面、HTTP API、模型接入和验证入口
  • session-agent-case
    • Session、共享工件、沙箱、并行调度、迁移逻辑
    • 被上层 Web 应用调用

工作目录示例：

bash 复制代码 
/Users/luqingjiedemac/gitcode_obj/openyuanrong2

其中主要关注：

text 复制代码 
openyuanrong2/
├── real-agent-openyuanrong/
└── session-agent-case/

三、整体架构

这次案例不是前端本地模拟，而是完整的三层结构：

text 复制代码 
浏览器页面
  -> app.js 发起 HTTP 请求
  -> server.py 接收请求
  -> agent_service.py 进行业务编排
  -> session-agent-case 中的 SessionManager / SessionActor / SandboxRunner / Benchmark / MigrationCoordinator
  -> openYuanrong SDK

上层页面能看到的内容主要有三类：

  • 多轮对话
  • 运行时工具
  • 会话沉淀数据

底层实际做的事情主要也有三类：

  • 管理 Session 实例和会话状态
  • 调用 openYuanrong 做实例绑定、对象共享、并发等待
  • 输出可以在终端直接观察到的运行日志

四、为什么说这个案例不是"假演示"

这一点需要先交代清楚，因为后面的五项验证都建立在这里。

4.1 openYuanrong 是通过 Docker 真实启动的

容器启动文件在：

  • real-agent-openyuanrong/docker-compose.yml
  • real-agent-openyuanrong/docker/app-entrypoint.sh

其中入口脚本里会先执行：

sh 复制代码 
yr start --master

只有在 openYuanrong Runtime 启动成功后，才会继续执行：

sh 复制代码 
python app.py

也就是说，上层 Web 服务不是脱离 openYuanrong 独立运行的，而是挂在这个运行时之上。

4.2 后端会输出明确的运行标记

服务启动后，可以在容器日志中看到类似内容：

text 复制代码 
Yuanrong deployed succeed
[real-agent][startup] 真实 Agent 服务已启动 {"yr_backend_mode": "real_sdk", ...}
[real-agent][server] 服务已启动: http://0.0.0.0:8080

这三类日志分别代表：

  • Yuanrong deployed succeed
    • 底层运行时已经起来
  • yr_backend_mode: real_sdk
    • 当前使用的不是假实现，而是真实 SDK
  • 服务已启动
    • Web 应用已经可提供对外接口

4.3 页面动作都对应后端 API

页面按钮不是做本地 UI 演示，每个动作都会打到真实 API：

  • 新建会话 -> POST /api/sessions
  • 发送消息 -> POST /api/chat
  • 执行沙箱脚本 -> POST /api/tools/sandbox
  • 运行性能压测 -> POST /api/tools/benchmark
  • 模拟高负载迁移 -> POST /api/tools/migrate
  • 清空会话 -> POST /api/sessions/clear

这些 API 的入口在：

  • real-agent-openyuanrong/src/real_agent_openyuanrong/server.py

具体业务编排在：

  • real-agent-openyuanrong/src/real_agent_openyuanrong/agent_service.py

五、底层能力与五个方向的对应关系

这一部分是核心内容。不是简单地把五条需求贴到页面上，而是要把每一条和 openYuanrong 的具体用法对上。

5.1 方向一：Session 亲和调度，多轮会话

对应代码：

  • session-agent-case/src/session_agent_case/session_manager.py
  • session-agent-case/src/session_agent_case/gateway.py

实际使用到的点：

  • yr.instance(...)
  • yr.get_instance(...)
  • InvokeOptions.name
  • need_order = True
  • concurrency = 1

当前实现思路：

  1. 每个 session_id 对应一个命名的 SessionActor
  2. 新请求到来时，先按 session_id 查找现有实例
  3. 如果实例存在，就继续复用
  4. 如果不存在，再新建一个

这样做的直接结果就是：同一个会话的第二轮、第三轮消息，不会落到新的无状态实例里，而是继续回到原来的 Session 实例。

5.2 方向二：Session 抽象、自动管理、共享对象

对应代码：

  • session-agent-case/src/session_agent_case/models.py
  • session-agent-case/src/session_agent_case/session_manager.py
  • session-agent-case/src/session_agent_case/session_actor.py
  • session-agent-case/src/session_agent_case/datasystem_store.py

实际使用到的点：

  • SessionRequest
  • SessionState
  • SessionMetadata
  • SessionManager
  • yr.put(...)
  • yr.get(...)

这里做的不是简单的"把几条消息放在内存里"，而是做了三层抽象：

  • 请求抽象：一条请求进入系统后，用 SessionRequest 统一表达
  • 状态抽象：会话里的历史、当前目标、工件、节点、状态，都放在 SessionState
  • 生命周期抽象：创建时间、访问时间、节点、迁移版本等放在 SessionMetadata

共享工件这一块依赖 yr.put / yr.get。这意味着工件不是只在当前函数里短暂存在，而是可以用引用 ID 回写到 Session 状态中，后续继续读取。

5.3 方向三：沙箱调度和 Sandbox API

对应代码：

  • real-agent-openyuanrong/src/real_agent_openyuanrong/agent_service.py
  • session-agent-case/src/session_agent_case/sandbox_runner.py

实际使用到的点：

  • 独立的 Sandbox API
  • SandboxPolicy
  • 超时约束
  • 禁用网络访问
  • 执行结果写回会话

这次验证里，沙箱不是"对话区里顺手执行一段代码"，而是专门走一条后端接口：

  1. 页面输入脚本
  2. 调用 POST /api/tools/sandbox
  3. 后端执行受控代码
  4. 把 stdout / stderr / returncode / timed_out 返回页面
  5. 同时把结果沉淀成共享工件

说明一下边界：

这个沙箱实现用于案例验证是够用的，它确实执行了真实代码，也有限制策略和超时控制；但如果作为生产级强隔离方案，还需要继续往下叠加容器级隔离、系统调用限制、资源配额等机制。

5.4 方向四：wait/notify 与吞吐提升

对应代码：

  • session-agent-case/src/session_agent_case/benchmark.py
  • session-agent-case/src/session_agent_case/session_actor.py

实际使用到的点：

  • yr.wait(...)
  • yr.get(...)
  • 多任务并发执行

这项验证的做法比较直接：

  1. 先跑一轮串行任务
  2. 再跑一轮并行任务
  3. 用 yr.wait 等待所有并发任务完成
  4. 最后计算串行和并行的总耗时差

因此页面上看到的 吞吐提升 xx% 不是写死的展示值，而是一次实际 benchmark 的结果。

5.5 方向五：Session 迁移与弹性

对应代码：

  • session-agent-case/src/session_agent_case/migration.py
  • session-agent-case/src/session_agent_case/session_manager.py
  • session-agent-case/src/session_agent_case/load_tracker.py

实际使用到的点：

  • 会话快照导出
  • 会话快照恢复
  • 节点负载判断
  • 节点重新绑定

这里验证的是"迁移语义"，不是跨机器热迁移。当前案例运行在单机 Docker 中，所以实现方式是：

  1. 先模拟节点负载不均
  2. 导出当前 Session 快照
  3. 用快照恢复新的实例
  4. 把 Session 绑定到低负载节点

这个实现足够验证两件事：

  • 会话可以在负载压力下迁移
  • 迁移后上下文不会丢

六、部署方式

6.1 前置条件

需要准备：

  • Docker 环境
  • 能运行 Linux 容器的本机环境
  • 一个可用的大模型 API Key

6.2 启动目录（先下载 openYuanrong 运行时 wheel）

进入项目目录后，先执行：

bash 复制代码 
chmod +x scripts/download_runtime_wheels.sh
./scripts/download_runtime_wheels.sh

这个脚本会通过 python:3.11-slim 容器下载 Linux amd64 版本所需的：

  • openyuanrong==0.7.0
  • 以及它的构建和运行依赖

下载完成后，文件会落到：

text 复制代码 
real-agent-openyuanrong/docker/runtime-wheels/amd64

如果你们内部使用自建 Python 包源，也可以先设置：

bash 复制代码 
export PIP_INDEX_URL='你的 Python 包源'
export PIP_EXTRA_INDEX_URL='你的额外包源'

再执行下载脚本。

6.3 启动命令

如果使用 Kimi 兼容接口，启动方式如下：

bash 复制代码 
OPENAI_API_KEY='你的密钥' \
OPENAI_BASE_URL='https://api.moonshot.cn/v1' \
OPENAI_MODEL='moonshot-v1-8k' \
docker compose up --build -d --force-recreate

6.4 检查容器状态

bash 复制代码 
docker ps --filter name=real-agent-openyuanrong-app

正常情况下会看到：

text 复制代码 
real-agent-openyuanrong-app

6.5 检查启动日志

bash 复制代码 
docker logs --tail 120 real-agent-openyuanrong-app

正常情况下，至少应看到：

text 复制代码 
Yuanrong deployed succeed
[real-agent][startup] 真实 Agent 服务已启动 ...
[real-agent][server] 服务已启动: http://0.0.0.0:8080

6.6 健康检查

bash 复制代码 
curl http://127.0.0.1:8090/api/health

正常返回里应包含：

  • status: ok
  • service: real-agent-openyuanrong
  • yr_backend_mode: real_sdk

6.7 打开页面

text 复制代码 
http://127.0.0.1:8090

6.8 建议保留两个终端窗口

窗口一，用来观察启动状态：

bash 复制代码 
docker logs --tail 120 real-agent-openyuanrong-app

窗口二，用来实时观察验证过程：

bash 复制代码 
docker logs -f --tail 0 real-agent-openyuanrong-app

七、五项能力的实际验证步骤

这一部分按实际操作顺序写。为了避免旧数据干扰，建议每次正式复现前，先在页面左侧点击一次 清空会话。

7.1 验证一：Session 亲和调度，多轮会话

页面操作
  1. 点击 新建会话
  2. 在输入框输入：
text 复制代码 
这个项目启动失败，提示数据库连接异常，请先帮我分析可能原因。
  1. 点击 发送
  2. 再输入：
text 复制代码 
继续基于上一轮结论，给我一个排查顺序，并告诉我先看哪两个日志。
  1. 再次点击 发送
页面现象
  • 左侧只有一个会话
  • 对话区连续出现两轮问答
  • 左侧消息数会增加
  • 当前节点通常保持不变，例如 node-a
终端现象

窗口二中应看到类似日志：

text 复制代码 
[real-agent][chat] 收到用户消息 ...
[real-agent][session] 会话持续命中同一实例 {"assigned_node":"node-a","history_items":4,"session_id":"agent-xxxx"}
说明

这里真正要看的不是页面里有没有两段文本，而是日志里的 session_id 和 会话持续命中同一实例。这说明第二轮请求回到了同一个 Session 实例，而不是重新建了一个无状态执行环境。

7.2 验证二：Session 抽象、自动管理、共享对象

页面操作

沿用上一条中的会话，不要新建新的。继续发送：

text 复制代码 
结合前面内容，帮我总结一下当前上下文里已经确认的信息。
页面现象

重点看两个位置：

  • 左侧会话列表
    • 消息 数增加
    • 工件 数增加
  • 页面下方 会话沉淀
    • 共享工件 有新增条目
    • 调度事件 有新增记录
终端现象

应看到类似日志：

text 复制代码 
[real-agent][artifact] 共享对象状态已更新 {"session_id":"agent-xxxx","shared_artifact_count":N}
说明

这一条要证明的是：系统里存在一个真正的会话管理层，而不是前端把历史消息堆在一起。共享工件数的增长，说明结果已经沉淀到了会话上下文里，后续可以继续复用。

7.3 验证三：安全沙箱调度和 Sandbox API

页面操作
  1. 仍然沿用当前会话
  2. 在右侧 运行时工具 的沙箱输入框中输入：
python 复制代码 
print(40 + 2)
  1. 点击 执行沙箱脚本
页面现象
  • 对话区新增一条沙箱执行结果相关回复
  • 共享工件 中增加一个 sandbox_result
终端现象

应看到类似日志：

text 复制代码 
[real-agent][sandbox] 开始执行沙箱验证脚本 {"session_id":"agent-xxxx"}
[real-agent][sandbox] 沙箱执行器已返回结果 {"returncode":0,"session_id":"agent-xxxx","timed_out":false}
[real-agent][sandbox] 沙箱执行完成 {"returncode":0,"session_id":"agent-xxxx","stderr":"","stdout":"42","timed_out":false}
说明

这里的证据比较直接：页面点击之后，后端确实执行了代码，并返回了真实输出 42。如果只是前端假演示，这一串后端日志不会出现，也不会有明确的 returncode 和 stdout。

7.4 验证四：wait/notify 与吞吐提升

页面操作

点击右侧：

text 复制代码 
运行性能压测
页面现象

压测卡片会显示：

  • 串行执行耗时
  • 并行执行耗时
  • 吞吐提升百分比

正常情况下，并行耗时应明显低于串行耗时。

终端现象

终端中应看到：

text 复制代码 
[real-agent][scheduler] 并行调度性能压测完成 {"improvement_percent":xx,"parallel_duration_sec":xx,"serial_duration_sec":xx,"session_id":"agent-xxxx"}
说明

这条不靠主观判断，而是直接看 benchmark 结果。improvement_percent 如果大于 30，就能支撑"吞吐提升 30%"这个方向。

7.5 验证五：Session 迁移与弹性

页面操作

点击右侧：

text 复制代码 
模拟高负载迁移
页面现象

页面中的迁移卡片应出现：

  • node-a -> node-b
  • 迁移状态: migrated
  • 迁移后节点: node-b
终端现象

通常先后出现两类日志。

第一类：

text 复制代码 
[real-agent][migration] 检测到节点负载不均，准备迁移会话 {"loads":{"node-a":0.93,"node-b":0.17},"session_id":"agent-xxxx"}

第二类：

text 复制代码 
[real-agent][migration] 会话迁移已完成 {"source_node":"node-a","target_node":"node-b","post_migrate_node":"node-b","status":"migrated",...}
补充验证

迁移完成后，再发送一句：

text 复制代码 
继续基于迁移前的上下文，给我最终修复建议。

如果还能继续正常回答，并且会话仍然沿用同一个 session_id，说明这次迁移不是"新开会话"，而是保留上下文的迁移。

说明

这一条在单机环境下验证的是"迁移逻辑"而不是"跨物理节点热迁移"。但对于"高负载场景下会话能转移，且上下文不丢"这个目标来说，证据是足够的。

八、页面按钮到后端调用的对应关系

为了方便审核时快速定位，这里再单独列一次按钮与调用链。

8.1 新建会话

  • 页面按钮：新建会话
  • 前端调用：POST /api/sessions
  • 后端入口：server.py
  • 业务方法：InteractiveAgentService.create_session(...)

8.2 发送消息

  • 页面动作：输入内容后点击 发送
  • 前端调用：POST /api/chat
  • 业务方法：InteractiveAgentService.chat(...)
  • 底层链路：SessionGateway -> SessionManager -> SessionActor

8.3 执行沙箱脚本

  • 页面按钮：执行沙箱脚本
  • 前端调用：POST /api/tools/sandbox
  • 业务方法：InteractiveAgentService.run_sandbox(...)
  • 底层链路：SandboxRunner.run_code_safe(...)

8.4 运行性能压测

  • 页面按钮：运行性能压测
  • 前端调用：POST /api/tools/benchmark
  • 业务方法：InteractiveAgentService.run_benchmark(...)
  • 底层链路：WaitNotifyBenchmark.run(...)

8.5 模拟高负载迁移

  • 页面按钮：模拟高负载迁移
  • 前端调用：POST /api/tools/migrate
  • 业务方法：InteractiveAgentService.simulate_migration(...)
  • 底层链路：MigrationCoordinator.maybe_migrate_overloaded_session(...)

九、这套验证的边界

为了避免误导，这里把边界写清楚。

9.1 关于"真实"

这套验证是真实的，指的是：

  • openYuanrong Runtime 真实启动了
  • Web 页面真实调用了后端
  • Session、共享工件、并发等待、迁移逻辑都真实执行了
  • 终端日志和页面状态可以相互对应

9.2 关于"生产级能力"

两点边界：

  • 沙箱目前是验证案例级实现，不等价于生产环境的强隔离执行平台
  • 迁移验证是单机环境下的逻辑迁移，不是跨机器热迁移

对于"验证 openYuanrong 是否具备支撑这些方向的能力"这个目标，这个案例是成立的。

十、结论

这次案例的核心不是"做了一个前端页面"，而是把 openYuanrong 在 Session、共享对象、并发等待、沙箱执行和会话迁移方面的能力，放进一个真实可交互的 Agent 应用里走通了一遍。

从代码实现、接口调用到终端日志，五个方向都能找到相应的支撑点：

  • 多轮会话依赖命名 Session 实例和实例复用
  • 共享工件依赖 Session 状态和对象引用存取
  • 沙箱验证依赖独立 API 和受控执行路径
  • 吞吐提升依赖 yr.wait 的并发等待
  • 迁移能力依赖快照恢复和节点重新绑定

如果审核目标是判断"openYuanrong 能不能支撑这样一类 Agent 场景"，这套案例可以作为一个可复现、可观察、可解释的验证样例。

本篇文章用到的所有的想都以开源

https://gitcode.com/lqjmac/session-agent-case

https://gitcode.com/lqjmac/real-agent-openyuanrong

相关推荐
中杯可乐多加冰5 小时前
Serverless 时代的内核革命——华为 openYuanrong 深度解析 异构多级缓存与 D2D 高速传输实测
缓存·华为·开源·serverless·openyuanrong
互联网散修6 小时前
零基础鸿蒙应用开发第四节：运算符与运算规则
华为·harmonyos
盐焗西兰花8 小时前
鸿蒙学习实战之路-Share Kit系列(11/17)-目标应用接收分享（分享详情页）
学习·华为·harmonyos
互联网散修9 小时前
零基础鸿蒙应用开发第二节：开发工具的功能介绍
华为·harmonyos
UnicornDev9 小时前
【HarmonyOS 6】个人中心数据可视化实战
华为·harmonyos·arkts·鸿蒙·鸿蒙系统
ujainu1 天前
在 HarmonyOS PC 上实现自定义窗口样式的 Electron 应用详解
华为·electron·harmonyos
盐焗西兰花1 天前
鸿蒙学习实战之路-Share Kit系列(10/17)-目标应用接收分享（应用内处理）
学习·华为·harmonyos
江湖有缘1 天前
基于开发者空间部署OtterWiki知识管理工具【华为开发者空间】
华为
fei_sun1 天前
【鸿蒙智能硬件】（六）使用鸿蒙app展示环境监测数据
华为·harmonyos
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03OpenClaw 使用和管理 MCP 完全指南04本地部署 OpenClaw + DeepSeek-R1 完全指南05UV安装并设置国内源06OpenClaw macOS 完整安装与本地模型配置教程（实战版）07OpenClaw Control UI安全上下文访问配置08Openclow安装保姆级教程09在 Windows 上配置 Claude Code从安装到解决网络问题10OpenClaw 飞书机器人不回复消息？3 小时踩坑总结