docs(workflow): optimize release format to English-only changelog
This commit is contained in:
fujie
@@ -32,7 +32,8 @@ This is an advanced Pipe function for [OpenWebUI](https://github.com/open-webui/
|
||||
- **🧠 Deep Database Integration**: Real-time persistence of TOD·O lists for long-running workflows.
|
||||
- **🌊 Advanced Streaming**: Full support for thinking process/Chain of Thought visualization.
|
||||
- **🖼️ Intelligent Multimodal**: Vision capabilities and raw file analysis support.
|
||||
- **⚡ Full-Lifecycle File Agent**: Supports receiving uploaded files for raw bypass analysis and publishing generated results (e.g., analyzed Excel/reports) as downloadable links—a complete closed-loop agentic workflow.
|
||||
- **⚡ Full-Lifecycle File Agent**: Supports receiving uploaded files for raw bypass analysis and publishing results (Excel/reports) as downloadable links.
|
||||
- **🖼️ Interactive Artifacts**: Automatically renders HTML/JS apps generated by the agent directly in the chat interface.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -32,7 +32,8 @@
|
||||
- **🧠 深度数据库集成**: 实时持久化 TOD·O 列表到 UI 进度条。
|
||||
- **🌊 深度推理展示**: 完整支持模型思考过程 (Thinking Process) 的流式渲染。
|
||||
- **🖼️ 智能多模态**: 完整支持图像识别与附件上传分析。
|
||||
- **⚡ 全生命周期文件 Agent**: 支持接收上传文件进行绕过 RAG 的深度分析，并将处理结果（如分析后的 Excel/报告）发布为可下载链接，实现完整的闭环 Agent 工作流。
|
||||
- **⚡ 全生命周期文件 Agent**: 支持接收上传文件进行绕过 RAG 的深度分析，并将处理结果（如 Excel/报告）发布为下载链接。
|
||||
- **🖼️ 交互式伪影 (Artifacts)**: 自动渲染 Agent 生成的 HTML/JS 应用程序，直接在聊天界面交互。
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -134,10 +134,10 @@ BASE_GUIDELINES = (
|
||||
" - 2. **Render**: Immediately output the SAME code in a ` ```html ` block so the user can interact with it.\n"
|
||||
" - **Result**: The user gets both a saved file AND a live app. Never force the user to choose one over the other.\n"
|
||||
"4. **Images & Files**: ALWAYS embed generated images/files directly using ``. Never provide plain text links.\n"
|
||||
"5. **File Delivery & Publishing (CRITICAL)**:\n"
|
||||
" - **Implicit Requests**: If the user says 'publish this', 'export your response', or 'give me a link to this content', you MUST: 1. Write the relevant content to a `.md` (or other appropriate) file in the current directory (`.`). 2. Call `publish_file_from_workspace(filename='name.md')` to get a link.\n"
|
||||
" - **Manual Sequence**: 1. **Write Local**: Create the file in `.` (your only workspace). 2. **Publish**: Call `publish_file_from_workspace(filename='your_file.ext')`. **WARNING**: You MUST provide the filename argument; never call this tool with empty parentheses.\n"
|
||||
" - *Rule*: Only files in the current directory (`.`) can be published. The tool bypasses RAG and handles S3/Local storage automatically.\n"
|
||||
"5. **File Delivery & Publishing (Complementary Goal)**:\n"
|
||||
" - **Philosophy**: Publishing files is essential when the user needs to *possess* the data (download, edit offline, archive). However, this should **NOT** replace chat-page visualizations (HTML artifacts, Mermaid, Markdown tables). Aim for 'Visual First + File for Persistence'.\n"
|
||||
" - **Implicit Requests**: If the user wants to 'get' or 'export' something, you MUST: 1. Visualize/summarize in the chat. 2. Write to a local file. 3. Call `publish_file_from_workspace`. 4. Provide the link.\n"
|
||||
" - **Standard Sequence**: 1. **Write Local**: Create file in `.` (only workspace). 2. **Publish**: Call `publish_file_from_workspace(filename='your_file.ext')`. 3. **Link**: Present the `download_url` as a Markdown link.\n"
|
||||
"6. **TODO Visibility**: Every time you call the `update_todo` tool, you **MUST** immediately follow up with a beautifully formatted **Markdown summary** of the current TODO list. Use task checkboxes (`- [ ]`), progress indicators, and clear headings so the user can see the status directly in the chat.\n"
|
||||
"7. **Python Execution Standard**: For ANY task requiring Python logic (not just data analysis), you **MUST NOT** embed multi-line code directly in a shell command (e.g., using `python -c` or `<< 'EOF'`).\n"
|
||||
' - **Exception**: Trivial one-liners (e.g., `python -c "print(1+1)"`) are permitted.\n'
|
||||
|
||||
@@ -63,10 +63,10 @@ FORMATTING_GUIDELINES = (
|
||||
"1. **Markdown & 多媒体**：自由使用粗体、斜体、表格和列表。\n"
|
||||
"2. **Mermaid 图表**：请务必使用标准的 ```mermaid 代码块。\n"
|
||||
"3. **交互式 HTML/JS**：你可以输出完整的 ```html 代码块（含 CSS/JS），将在 iframe 中渲染。\n"
|
||||
"4. **文件交付与发布 (关键规范)**：\n"
|
||||
" - **隐式请求**：若用户要求“发布这个”、“导出刚才的内容”或“给我一个链接”，你必须：1. 将内容写入当前目录 (`.`) 下的 `.md` (或其他合适) 文件。2. 调用 `publish_file_from_workspace(filename='name.md')` 获取链接。\n"
|
||||
" - **标准流程**：1. **本地写入**：使用 Python 在**当前目录 (`.`)** 创建文件。这是你的唯一工作区。**严禁**使用 `/tmp` 等绝对路径。2. **显式发布**：调用 `publish_file_from_workspace(filename='your_file.ext')`。该工具会自动同步至 S3 并绕过 RAG。3. **呈现链接**：从工具返回的 JSON 中提取 `download_url`，并以 Markdown 链接 `[点击下载描述](url)` 展示。\n"
|
||||
" - **规则**：只有当前目录 (`.`) 下的文件可以发布。调用时必须传入 `filename` 参数，严禁空调用。\n"
|
||||
"4. **文件交付与发布 (互补目标)**：\n"
|
||||
" - **设计理念**：当用户需要“拥有”数据（下载、离线编辑、归档）时，发布文件是必不可少的。但这**不应**取代聊天页面的视觉化展示（如 HTML 应用、Mermaid 图表、Markdown 表格）。应追求“直观预览 + 持久产物”的双重体验。\n"
|
||||
" - **隐式请求**：若用户要求“获取内容”或“导出数据”，你应当：1. 在聊天中进行视觉化汇总/预览。2. 将完整内容写入本地文件。3. 调用 `publish_file_from_workspace`。4. 展示下载链接。\n"
|
||||
" - **标准流程**：1. **本地写入**：在当前目录 (`.`) 创建文件。2. **发布文件**：调用 `publish_file_from_workspace(filename='your_file.ext')`。3. **呈现链接**：从返回结果中提取 `download_url` 并在回复末尾展示。\n"
|
||||
"7. **主动与自主**: 你是专家工程师。对于显而易见的步骤，**不要**请求许可。**不要**停下来问“我通过吗？”或“是否继续？”。\n"
|
||||
" - **行为模式**: 分析用户请求 -> 制定计划 -> **立即执行**计划。\n"
|
||||
" - **澄清**: 仅当请求模棱两可或具有高风险（例如破坏性操作）时才提出问题。\n"
|
||||
|
||||
Reference in New Issue
Block a user