WorkBuddy ACP 突破方案

❌ 问题描述

⚠️ WorkBuddy 4.22+ ACP 安全策略拦截

核心问题：WorkBuddy 升级到 4.22+ 后，ACP（Agent Control Policy）安全策略对 Python/Node 等子进程的 stdout 和 stderr 进行拦截，导致所有自动化任务无法获取脚本执行输出。

维度	升级前	升级后
子进程输出	✅ 正常返回	❌ 被吞掉
自动化任务	✅ 全链路可用	❌ 无法获取结果
调试能力	✅ 可看日志	❌ 黑盒执行
错误反馈	✅ 实时报错	❌ 静默失败

💡 解决方案

🧠 降维打击：从进程层跳到网络层

核心思路：既然 WorkBuddy 在操作系统层锁死了父子进程的管道通信（Pipe），那我们就跳出进程树限制，改走网络层（Network）—— 建立 Local API Bridge，让 WorkBuddy 从"执行者"变成"发令者"。

"WorkBuddy 从一个执行者变成了发令者，而真正的重活儿由运行在安全区外的代理服务完成。这不仅解决了输出被吞的问题，还顺带解决了权限受限和调试困难的痛点。"

🤖

WorkBuddy

下达指令

→

📡

Invoke-RestMethod

网络请求替代进程调用

→

🌉

LAB 代理服务

127.0.0.1:58080

→

🐍

Python 执行

宿主机运行 · 完整输出

🔧 实施步骤

三步搞定

Step 1 — 启动 LAB 中转服务

在 WorkBuddy 沙箱外部启动轻量 HTTP API 代理，监听本地端口 58080。

Step 2 — 修改调用方式

不再直接调用 Python，改用 PowerShell 发起网络请求：

PowerShell

$body = ConvertTo-Json @{
    cmd = "python C:\path\to\your_script.py"
    cwd = "C:\path\to\project"
}

$response = Invoke-RestMethod -Uri "http://127.0.0.1:58080/call" -Method Post -Body $body -ContentType "application/json"

# 获取完整输出
Write-Output $response.stdout
if ($response.code -ne 0) { Write-Error $response.stderr }
        

Step 3 — 拿回完整输出

LAB 代理在宿主机执行脚本后，将 stdout、stderr、exitCode 包装在 JSON 中返回，彻底恢复执行可见性。

JSON Response

{
  "stdout": "执行输出完整内容...",
  "stderr": "错误信息（如有）",
  "code": 0
}
        

🔌 API 接口

LAB 服务接口一览

POST /call

✅ 推荐接口 · 执行命令并返回完整输出

POST /exec

兼容旧版 · 功能同 /call

GET /health

健康检查 · 确认服务运行中

/call 接口详情

Request / Response

// 请求
{
  "cmd": "python xxx.py",
  "cwd": "项目目录"
}

// 响应
{
  "stdout": "执行输出",
  "stderr": "错误信息",
  "code": 0
}
        

📊 方案评估

四维评估

✅

可行性

Socket 通信绕过 ACP Pipe 拦截，验证成功

⚡

工作量

无需修改业务代码，仅封装调用逻辑

🛡️

稳定性

解决 stdout 丢失，支持实时报错反馈

🔒

合规性

Loopback 请求被 ACP 放行，不破坏安全策略

✅ 验证成果

已验证项目

应急管理部微博周报 — 数据抓取 → 周报生成 → Telegram 推送，全链路成功

LAB 模式下，stdout、stderr、exitCode 均可正常返回，自动化任务完全恢复控制能力。

⚠️ 注意事项

🔸
临时方案 — 等官方 ACP 策略修复后会恢复原路径
🔸
LAB 服务需保持运行 — 端口 58080，后台常驻
✅
无需修改业务代码 — 仅需封装调用逻辑
✅
完整输出返回 — stdout、stderr、exitCode 均可获取