[Feature]: 无沙箱环境运行时，运行skill脚本技能的产物读取不到

[oyx888]

/workspace 初始化智能体时工作目录配置的路径，session隔离权限，观测到调用llm时Middleware会在提示词新增工作目录路径，会以/workspace为工作目录，llm执行脚本命令时就会以/workspace为根目录去执行脚本文件，脚本执行出来的产物也是在/workspace ，list_file工具只会读取/workspace/session_xxx 的文件夹下的文件，导致agent获取不到skill的产物

[oss-maintainer]

Issue Evaluation

Category: enhancement | Status: Evaluated

When running without a sandbox, the middleware injects /workspace as the working directory, so skill scripts execute with /workspace as root and write their artifacts there. However list_file (under session isolation) only enumerates /workspace/session_xxx, so skill-produced artifacts in /workspace are invisible to the agent.

Feasibility: needs-discussion. This is a path-scoping mismatch between where skill scripts run/write and what list_file exposes under session isolation. Options include scoping skill execution to the session directory, or allowing list_file to expose a declared artifact directory for the current session.
Scope: harness workspace / filesystem tools (agentscope-harness).
Compatibility: any change must respect session isolation and not leak other sessions' files.

Could you share how the workspace/working directory is configured (is /workspace intentional vs the session dir?) and the exact list_file call + observed output? That will help pinpoint whether this is a config expectation issue or a tool-scoping defect.

---

Automated evaluation by github-manager-bot

[oyx888]

Issue Evaluation  问题评估

Category: enhancement | Status: Evaluated类别: enhancement | 状态: 已评估

When running without a sandbox, the middleware injects /workspace as the working directory, so skill scripts execute with /workspace as root and write their artifacts there. However list_file (under session isolation) only enumerates /workspace/session_xxx, so skill-produced artifacts in /workspace are invisible to the agent.在不使用沙箱环境的情况下，中间件会将 /workspace 作为工作目录进行设置，因此技能脚本会以 /workspace 作为根用户来执行，并将生成的工件保存在那里。不过， list_file （处于会话隔离状态）只能枚举 /workspace/session_xxx ，所以由技能生成的工件在 /workspace 目录下对代理来说是不可见的。

Feasibility: needs-discussion. This is a path-scoping mismatch between where skill scripts run/write and what list_file exposes under session isolation. Options include scoping skill execution to the session directory, or allowing list_file to expose a declared artifact directory for the current session.可行性：需要讨论。这里存在路径规划上的不匹配问题，即技能脚本的运行/写入位置与 list_file 在会话隔离下的暴露路径并不一致。可能的解决方案是将技能执行的路径限定在会话目录内，或者允许 list_file 在当前会话中暴露指定的工件目录。 Scope: harness workspace / filesystem tools (agentscope-harness).适用范围：适用于工具箱工作区/文件系统中的工具（agentscope-harness）。 Compatibility: any change must respect session isolation and not leak other sessions' files.兼容性：所有的修改都必须遵循会话隔离的原则，并且不得泄露其他会话中的文件数据。

Could you share how the workspace/working directory is configured (is /workspace intentional vs the session dir?) and the exact list_file call + observed output? That will help pinpoint whether this is a config expectation issue or a tool-scoping defect.您可以描述一下工作区/工作目录的配置情况如何？（是 /workspace 故意这么做的，还是会话目录本身的设置问题？）另外，请详细说明 list_file 的调用过程以及观察到的输出结果。这样就能判断这是否属于配置方面的问题，还是工具使用上的缺陷。

Automated evaluation by github-manager-bot由 github-manager-bot 进行的自动化评估

目前我是使用一个agent测试，不同用户并发agent单实例的情况，以session为隔离，进行多个用户使用这一个agent，同时并发不同的会话窗口进行对话，HarnessAgent.builder().workspace("/workspace")这是agent设置的工作目录，比如明确发出"帮我使用docx技能生成一个测试word文档"，Middleware会在提示词中告诉llm /workspace是工作区，首先llm会使用load_skill工具去读取SKILL.md文档，然后exec执行命令工具去读/workspace 下面的脚本，这里有个问题，很多模型是只会使用工具去读取SKILL.md文档其余脚本文件等都是使用exec执行命令去读取，读取到skill中的脚本之后，llm会按照skill文档中的提示词生成一个python脚本，使用write_file写入到/workspace/1中生成一个gen_test.py，这个1就代表session，生成完文件之后，llm下一步直接就是exec执行命令python /workspace/gen_test.py /workspace/test.docx，这时候就会报错了文件不存在给llm，llm经过N轮exec命令执行读取了其它很多session文件夹下的文件，在1里面找到了，如果期间其它session出现了同名文件，那llm就会把这个文件复制到/workspace下，那也会出现不同session会话文件串了，复制py文件过来之后，llm再执行python命令，生成了/workspace/test.docx文件，然后现在就有个问题了，用list_file拿不到文件了，因为不在/workspace/1中，llm如果不聪明的时候直接死循环了，导致循环次数耗尽，我临时的修改方案就是在关闭了disableWorkspaceContext，自己写了一个WorkspaceContext，告诉了llm实际的工作区是动态拼接每轮对话session，/workspace/1，然后执行技能脚本时就正确了，即使不使用skill的情况下，如果出现读取docx等文档时，agent没挂任何工具第三方mcp，agent会自主写了python脚本读取，也会出现这种情况，会出现多个对话不同用户在/workspace生成一大堆的脚本文件和产物，用户展示界面有拿不到产物，不修复目前做不了文档相关操作的功能