问题描述
这个问题解决了什么痛点？
目前，Subagent（子代理）完全无法执行宿主机上的 CLI 命令，特别是像 mcporter 这样的内部中间件工具。即使用户在本地已经完美配置了环境，Subagent 依然无法调用。
根本原因分析：
- 工具集受限： Subagent 运行在受限的沙箱中，通常被剥夺了
run_in_terminal权限，或者无法访问宿主机 Shell。 - 环境隔离： Subagent 不继承宿主机的
PATH、环境变量及认证 Token。即使安装了mcporter，Subagent 也找不到二进制文件或无法通过鉴权。 - 网络与特权隔离：
mcporter依赖本地回环网络和本地凭证，这些"宿主机特权"被沙箱天然隔绝。
解决方案
它应该如何工作？
建议提供一种机制，在保持安全的前提下，打通 Subagent 与宿主机 CLI 的交互：
- 环境变量白名单继承： 允许在主配置中定义"安全环境变量白名单"（如
PATH,MCPORTER_TOKEN等），Subagent 启动时可继承这些特定变量，从而获得环境上下文。 - 可信命令授权机制： 引入"允许 Subagent 执行的命令列表"。用户可以在配置中显式声明允许 Subagent 运行
mcporter，系统据此动态开放沙箱权限。 - 主代理代理执行模式： 如果直接开放沙箱风险过大，可以设计一种"委托执行"机制：Subagent 发出执行请求 → 主代理（Main Agent）拦截并询问用户/自动确认 → 主代理在宿主机执行命令 → 将结果返回给 Subagent。
使用场景
什么时候会用到这个功能？
这在涉及 DevOps、部署运维、本地工具链集成 的场景中是必须的。
- 场景： 用户创建一个
deploy-agent用于自动化部署。 - 工作流： 该 Agent 需要执行
mcporter list检查服务状态，或执行mcporter deploy推送更新。 - 当前困境： 由于沙箱限制，Agent 报错"命令未找到"或"权限被拒绝"，导致自动化流程中断，用户不得不手动介入。
优先级
高 - 阻碍性问题
(如果不解决此问题，Subagent 将无法承担任何涉及本地系统操作或内部工具调用的复杂任务，极大地限制了其自动化能力。)
补充信息
- 影响范围： 这不仅影响
mcporter，所有依赖本地环境配置的 CLI 工具（如kubectl,docker, 内部运维脚本等）都会受此影响。 - 技术建议： 可以参考 VS Code Tasks 或 Docker 容器的环境变量注入机制，实现一种受控的、可配置的环境透传方案。