AIClaw already let agents run tools, generate files, and continue working across steps. The weak point was the handoff back to the user: a tool might create a report, image, or data file, but the final answer did not always make that output obvious or directly downloadable.
Recent AIClaw changes tightened that workflow. Tool-generated files are now collected, deduplicated, exposed in API responses and streaming completion chunks, linked into the final assistant message, and rendered by the chat UI through stable /public/files/<uuid>
download URLs.
This is not a cosmetic change. It closes the loop between tool execution and user-visible results.
In a tool-using agent system, “I created the file” is not enough. Users need to:
Without that, generated artifacts are easy to lose, especially when an agent uses multiple tools or delegates work to sub-agents.
The recent attachment work is visible across the backend and frontend.
On the execution side, AIClaw now:
sub_agent
resultsYou can see that in the tool execution path:
/Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/tool_call.go
/Users/yu/go/src/github.com/chowyu12/aiclaw/internal/agent/executor.go
The final assistant response now appends an attachment section with Markdown links such as:
Attachment List:
- [report.csv](/public/files/<uuid>)
- [chart.png](/public/files/<uuid>)
In the current Chinese codebase revision, that section is rendered as 附件列表
in the saved final content.
The response payload also includes files directly:
files
done
chunks now include files
That path is visible in:
/Users/yu/go/src/github.com/chowyu12/aiclaw/internal/model/message.go
/Users/yu/go/src/github.com/chowyu12/aiclaw/internal/handler/chat.go
/Users/yu/go/src/github.com/chowyu12/aiclaw/web/src/api/chat.ts
On the frontend, the chat view turns those file objects into clickable downloads through /public/files/${file.uuid}
:
This feature is useful anywhere an AIClaw agent produces artifacts instead of pure text.
Examples:
code_interpreter
task generates a CSV and a PNG chart.Before this improvement, users could still end up asking, “Where did the file go?”
Now the expected workflow is much cleaner:
That means AIClaw behaves more like a practical work system and less like a text-only chatbot that happens to call tools.
One useful part of this change is that file outputs are not limited to the top-level agent.
The executor now extracts file references from sub_agent
results and folds them back into the parent response. That matters because many real AIClaw workflows split research, scraping, or data prep into delegated tasks. If child artifacts disappear at the parent boundary, the system feels unreliable.
Bringing those files back into the parent answer makes nested agent execution much easier to trust.
The same change set also adds SSE ping support in chat streaming handlers. That is separate from attachments, but it helps long-running tool workflows stay alive while the agent is still working.
For attachment-heavy runs, that pairing is useful:
done
chunk can carry the generated filesThis is a good example of AIClaw’s local-first, tool-oriented design philosophy. The platform is not just trying to produce a nice paragraph. It is trying to complete work and return the artifacts that work produces.
Generated files are often the real output. Making them first-class in the response path is the right move.
If you are building with AIClaw, this is the kind of feature that improves daily usability more than another abstract prompt tweak.