docs: add technical architecture guide
@@ -0,0 +1,221 @@
|
||||
# 01. 基座 Runtime 架构
|
||||
|
||||

|
||||
|
||||
## 1. 项目定位
|
||||
|
||||
ZK Data Agent 的定位不是通用聊天机器人,也不是单人本地 IDE Agent,而是面向团队业务流程的 Web Agent 工作台。
|
||||
|
||||
它基于已有的本地工程 Agent 能力继续往上搭:
|
||||
|
||||
- `LocalCodingAgent` 提供多轮 Agent Loop。
|
||||
- OpenAI-compatible client 提供模型调用适配。
|
||||
- Tool registry 和 handler 提供可控执行能力。
|
||||
- Session workspace 提供每个会话独立的输入、中间文件和产物目录。
|
||||
- Skill system 把流程协议、业务知识、脚本和样例打包成可复用能力。
|
||||
- Memory worker 把用户偏好和 Skill 使用经验异步整理为可编辑记忆。
|
||||
|
||||
这个项目要解决的核心痛点是:团队里的数据开发、线上挖掘、标签判断等流程,往往散在口头经验、临时 prompt、个人脚本、聊天记录和本地文件里。每个人都能临时做一次,但很难让别人稳定复用、持续维护、形成可审计的产物链。
|
||||
|
||||
当前已经验证过的主要业务场景包括:
|
||||
|
||||
- `product-data`:从产品定义、标签边界、样例 query 或 badcase 出发,生成 canonical records,并导出流转 CSV、训练 JSONL、评测 CSV。
|
||||
- `online-mining-v2`:基于 ELK 日志挖掘线上样本,保留 request_id、timestamp、session、模型 prompt、模型输出、domain 等信息,并接入后续数据规范。
|
||||
- `label-master`:把复杂度、多指令、自动任务、标签定义、function 输出和边界经验整理为可检索知识体系。
|
||||
- 外部系统 Skill:ELK、SQL、模型迭代、飞书在线文档转换等能力以 Skill 方式接入,不侵入基座。
|
||||
|
||||
因此,基座 Runtime 的目标不是把某一条业务链路写死,而是提供一套稳定的承载层,让不同业务能力都能以 Skill 的方式运行、交付、沉淀和更新。
|
||||
|
||||
## 2. 基座解决的问题
|
||||
|
||||
基座不绑定某一个业务流程。它提供的是通用 Agent runtime:
|
||||
|
||||
- 多用户 Web 入口。
|
||||
- 多会话状态管理。
|
||||
- 模型选择和 OpenAI-compatible 调用。
|
||||
- Tool registry 和 tool handler 执行。
|
||||
- Skill 发现、启用和提示词注入。
|
||||
- 当前会话工作区。
|
||||
- 运行态、事件流、活动区和刷新恢复。
|
||||
- 用户记忆和 Skill 记忆后台。
|
||||
|
||||
业务能力例如 `product-data`、`online-mining-v2`、`label-master` 都跑在这个基座上。
|
||||
|
||||
## 3. 文字架构图
|
||||
|
||||
```text
|
||||
浏览器 / Web UI
|
||||
|
|
||||
| 用户消息、模型选择、Skill 启用、文件面板、停止运行
|
||||
v
|
||||
frontend/app
|
||||
|
|
||||
| /api/chat、/api/claw/*、/admin
|
||||
v
|
||||
backend/api/server.py
|
||||
|
|
||||
| 账号配置、会话目录、run manager、run_state_store、memory_manager
|
||||
v
|
||||
LocalCodingAgent
|
||||
|
|
||||
| build_session、prompt sections、tool_specs、Agent loop
|
||||
v
|
||||
OpenAICompatClient
|
||||
|
|
||||
| messages + tools -> model backend
|
||||
v
|
||||
模型
|
||||
|
|
||||
| assistant text 或 tool_calls
|
||||
v
|
||||
Tool Runtime
|
||||
|
|
||||
| read/write/python_exec/data_agent/MCP/search/bash
|
||||
v
|
||||
session workspace
|
||||
|
|
||||
| input / scratchpad / output / session.json
|
||||
v
|
||||
前端活动区和文件面板
|
||||
|
||||
运行结束后:
|
||||
|
||||
AgentRunResult
|
||||
-> session_store 持久化
|
||||
-> memory_manager.enqueue_interaction
|
||||
-> memory worker 异步整理
|
||||
-> 下一轮 render_injection 注入
|
||||
```
|
||||
|
||||
## 4. 关键代码入口
|
||||
|
||||
### 4.1 Web 后端入口
|
||||
|
||||
主要文件:
|
||||
|
||||
```text
|
||||
backend/api/server.py
|
||||
```
|
||||
|
||||
关键职责:
|
||||
|
||||
- 维护账号和会话配置。
|
||||
- 创建或复用 `LocalCodingAgent`。
|
||||
- 给 Agent 注入 `runtime_context`、记忆、Jupyter 上下文。
|
||||
- 记录 run event,并通过 NDJSON streaming 返回前端。
|
||||
- 运行结束后写入 elapsed、标题、memory event。
|
||||
|
||||
关键函数和位置:
|
||||
|
||||
```text
|
||||
backend/api/server.py:691 enabled_skill_names(...)
|
||||
backend/api/server.py:822 _build_agent(...)
|
||||
backend/api/server.py:853 agent_for(...)
|
||||
backend/api/server.py:866 run_lock_for(...)
|
||||
backend/api/server.py:1720 /api/chat 运行链路开始
|
||||
backend/api/server.py:1739 memory_manager.render_injection(...)
|
||||
backend/api/server.py:1751 emit_agent_event(...)
|
||||
backend/api/server.py:1897 序列化运行结果和 elapsed
|
||||
backend/api/server.py:1920 memory_manager.enqueue_interaction(...)
|
||||
backend/api/server.py:2034 StreamingResponse NDJSON
|
||||
```
|
||||
|
||||
### 4.2 Agent Runtime
|
||||
|
||||
主要文件:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py
|
||||
```
|
||||
|
||||
关键职责:
|
||||
|
||||
- 初始化 tool registry、plugin runtime、MCP runtime、search runtime 等。
|
||||
- 新会话用 `run(...)`,旧会话用 `resume(...)`。
|
||||
- 在 `_run_prompt(...)` 中执行完整 Agent loop。
|
||||
- 维护 usage、cost、tool_calls、events、file_history。
|
||||
- 在结束时持久化 session。
|
||||
|
||||
关键函数和位置:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:158 class LocalCodingAgent
|
||||
src/agent_runtime.py:195 __post_init__
|
||||
src/agent_runtime.py:413 run(...)
|
||||
src/agent_runtime.py:441 resume(...)
|
||||
src/agent_runtime.py:520 _run_prompt 主链路
|
||||
src/agent_runtime.py:552 tool_specs = [tool.to_openai_tool() ...]
|
||||
src/agent_runtime.py:619 for turn_index in range(...)
|
||||
src/agent_runtime.py:1008 遍历模型返回的 tool_calls
|
||||
src/agent_runtime.py:1490 _query_model(...)
|
||||
```
|
||||
|
||||
### 4.3 系统提示词
|
||||
|
||||
主要文件:
|
||||
|
||||
```text
|
||||
src/agent_prompting.py
|
||||
```
|
||||
|
||||
关键职责:
|
||||
|
||||
- 定义中控 Agent 身份。
|
||||
- 注入工具使用策略。
|
||||
- 注入工作空间边界。
|
||||
- 注入 Skill 列表。
|
||||
- 注入 ask_user 等 runtime 指导。
|
||||
|
||||
关键函数和位置:
|
||||
|
||||
```text
|
||||
src/agent_prompting.py:135 get_intro_section
|
||||
src/agent_prompting.py:155 get_doing_tasks_section
|
||||
src/agent_prompting.py:182 get_actions_section
|
||||
src/agent_prompting.py:196 get_workspace_boundary_section
|
||||
src/agent_prompting.py:210 get_using_your_tools_section
|
||||
src/agent_prompting.py:274 get_skill_guidance_section
|
||||
src/agent_prompting.py:414 get_ask_user_guidance_section
|
||||
```
|
||||
|
||||
## 5. 基座的分层职责
|
||||
|
||||
```text
|
||||
Web UI
|
||||
负责交互、展示、文件面板、活动区、Skill 勾选、管理后台。
|
||||
|
||||
Backend API
|
||||
负责账号、会话、模型配置、运行态、服务端事件流。
|
||||
|
||||
Agent Runtime
|
||||
负责 Agent loop、模型调用、工具调用、预算和持久化。
|
||||
|
||||
Prompting
|
||||
负责把规则、工具、公约、Skill 列表转成模型可见上下文。
|
||||
|
||||
Tool Runtime
|
||||
负责稳定执行动作,并把结果结构化回传给模型。
|
||||
|
||||
Skill System
|
||||
负责让业务流程、知识、脚本可被 Agent 发现和使用。
|
||||
|
||||
Workspace
|
||||
负责隔离每个用户和每个会话的输入、临时文件和交付产物。
|
||||
|
||||
Memory Worker
|
||||
负责从交互历史中异步整理长期偏好和 Skill 使用经验。
|
||||
```
|
||||
|
||||
## 6. 设计边界
|
||||
|
||||
基座只应该承载跨业务复用的稳定能力,例如:
|
||||
|
||||
- 工具执行。
|
||||
- 会话状态。
|
||||
- 运行态事件。
|
||||
- 工作区路径。
|
||||
- Skill 发现和启用。
|
||||
- 模型适配。
|
||||
- 记忆后台。
|
||||
|
||||
业务流程不应该写死在基座里。数据生成、线上挖掘、标签判断等变化快的流程应该沉到 Skill;确定性脚本应该放在对应 Skill 的 `scripts/` 下。
|
||||
@@ -0,0 +1,246 @@
|
||||
# 02. Agent Loop 执行机制
|
||||
|
||||

|
||||
|
||||
## 1. Agent Loop 的基本形态
|
||||
|
||||
Agent 每轮不是只调用一次模型,而是一个循环:
|
||||
|
||||
```text
|
||||
用户输入
|
||||
-> 构造 session 和 prompt
|
||||
-> 调模型
|
||||
-> 模型返回 assistant text 或 tool_calls
|
||||
-> 如果没有 tool_calls:输出最终回复,结束
|
||||
-> 如果有 tool_calls:执行工具
|
||||
-> 工具结果写回 session
|
||||
-> 下一轮模型继续读取工具结果
|
||||
-> 直到最终回复、预算超限、取消、max_turns 或 review 停止
|
||||
```
|
||||
|
||||
这个循环允许 Agent 做“观察-执行-再观察”的任务,例如:
|
||||
|
||||
- 先读文件,再决定是否需要抽取。
|
||||
- 先生成 plan,等待用户 review。
|
||||
- 先运行脚本,再根据校验结果修复。
|
||||
- 先查询线上数据,再抽样展示。
|
||||
|
||||
## 2. 新会话和恢复会话
|
||||
|
||||
新会话入口:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:413 run(...)
|
||||
```
|
||||
|
||||
关键动作:
|
||||
|
||||
```text
|
||||
1. 清理当前 managed_agent_id 和 resume_source_session_id。
|
||||
2. 创建 session_id。
|
||||
3. 创建 scratchpad_directory。
|
||||
4. 绑定 plan_runtime/task_runtime 到 scratchpad。
|
||||
5. 调 _run_prompt(...)
|
||||
6. 累计 usage。
|
||||
```
|
||||
|
||||
恢复会话入口:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:441 resume(...)
|
||||
```
|
||||
|
||||
关键动作:
|
||||
|
||||
```text
|
||||
1. 从 StoredAgentSession 恢复 AgentSessionState。
|
||||
2. 回放 file_history 和 compaction 信息。
|
||||
3. 设置 active_session_id 和 last_session_path。
|
||||
4. 恢复 plugin state。
|
||||
5. 复用已有 scratchpad_directory。
|
||||
6. 调 _run_prompt(...)
|
||||
```
|
||||
|
||||
这解释了为什么刷新页面、回到旧会话后,Agent 理论上可以继续同一个 session 的上下文,而不是新建一个任务。
|
||||
|
||||
## 3. `_run_prompt` 主链路
|
||||
|
||||
核心位置:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:520 _run_prompt 主体
|
||||
```
|
||||
|
||||
主链路关键步骤:
|
||||
|
||||
```text
|
||||
1. slash command 预处理。
|
||||
2. hook policy / plugin hook 修改 prompt。
|
||||
3. agent_manager.start_agent(...) 记录运行。
|
||||
4. 新建或复用 AgentSessionState。
|
||||
5. runtime_context prepend 到模型可见的用户消息。
|
||||
6. session.append_user(...)。
|
||||
7. tool_context 注入 scratchpad、plan_runtime、task_runtime。
|
||||
8. 生成 tool_specs。
|
||||
9. 初始化 usage、cost、tool_calls、events。
|
||||
10. 进入 turn loop。
|
||||
```
|
||||
|
||||
对应代码点:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:523 agent_manager.start_agent(...)
|
||||
src/agent_runtime.py:531 session = base_session or build_session(...)
|
||||
src/agent_runtime.py:539 _prepend_runtime_context(...)
|
||||
src/agent_runtime.py:543 session.append_user(...)
|
||||
src/agent_runtime.py:546 replace(self.tool_context, scratchpad_directory=...)
|
||||
src/agent_runtime.py:552 tool_specs = [tool.to_openai_tool() ...]
|
||||
src/agent_runtime.py:582 stream_events = _RuntimeEventBuffer(event_sink)
|
||||
src/agent_runtime.py:619 for turn_index in range(...)
|
||||
```
|
||||
|
||||
## 4. 模型调用和 tool_calls 判断
|
||||
|
||||
模型调用入口:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:1490 _query_model(...)
|
||||
```
|
||||
|
||||
非流式路径中:
|
||||
|
||||
```text
|
||||
turn = self.client.complete(
|
||||
session.to_openai_messages(),
|
||||
tool_specs,
|
||||
output_schema=...
|
||||
)
|
||||
```
|
||||
|
||||
模型能否返回 `tool_calls` 取决于:
|
||||
|
||||
- 当前 `messages`。
|
||||
- 系统提示词。
|
||||
- Skill 列表。
|
||||
- 工具描述和参数 schema。
|
||||
- 模型自身 tool calling 能力。
|
||||
|
||||
基座不会强制某个工具被调用。基座只把工具能力暴露给模型,并在模型返回 `tool_calls` 后负责执行。
|
||||
|
||||
## 5. 没有 tool_calls 时
|
||||
|
||||
如果模型本轮没有工具调用:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:763 if not turn.tool_calls
|
||||
```
|
||||
|
||||
后续可能有三种情况:
|
||||
|
||||
1. 直接输出最终回复。
|
||||
2. 如果模型输出被截断,自动追加 continuation prompt。
|
||||
3. 如果达到 continuation 限制,则追加提示并结束。
|
||||
|
||||
最终会:
|
||||
|
||||
```text
|
||||
session.append_assistant(...)
|
||||
_append_final_text_stream_events(...)
|
||||
AgentRunResult(...)
|
||||
_persist_session(...)
|
||||
```
|
||||
|
||||
## 6. 有 tool_calls 时
|
||||
|
||||
如果模型返回工具调用:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:1008 for tool_call in turn.tool_calls
|
||||
```
|
||||
|
||||
每个工具调用会:
|
||||
|
||||
```text
|
||||
1. tool_calls 计数 +1。
|
||||
2. 检查预算。
|
||||
3. session.start_tool(...) 写入工具开始消息。
|
||||
4. stream_events 追加 tool_start。
|
||||
5. 根据工具名执行 handler。
|
||||
6. 工具结果写回 session。
|
||||
7. stream_events 追加工具结果。
|
||||
8. 下一轮模型读取工具结果继续判断。
|
||||
```
|
||||
|
||||
关键代码点:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:1054 session.start_tool(...)
|
||||
src/agent_runtime.py:1060 stream_events.append(type='tool_start')
|
||||
src/agent_tools.py:60 execute_tool(...)
|
||||
src/agent_tools.py:76 execute_tool_streaming(...)
|
||||
```
|
||||
|
||||
## 7. 为什么 review 可以暂停流程
|
||||
|
||||
review 门禁不是特殊 UI 魔法,而是 Agent loop 的自然结果:
|
||||
|
||||
1. Skill 要求模型在某一步调用 review 工具。
|
||||
2. 工具创建 pending state,并返回需要展示的信息。
|
||||
3. Agent 生成回复,告诉用户需要确认。
|
||||
4. 当前 run 结束。
|
||||
5. 用户下一轮回复“确认”。
|
||||
6. Agent resume 旧 session,调用 confirm 工具。
|
||||
7. 后续流程继续。
|
||||
|
||||
例如 `product-data`:
|
||||
|
||||
```text
|
||||
data_agent_prepare_generation_goal
|
||||
-> pending goal
|
||||
-> 停止等待用户确认
|
||||
|
||||
data_agent_confirm_generation_goal
|
||||
-> confirmed_goal_id
|
||||
-> data_agent_prepare_generation_plan
|
||||
-> pending plan
|
||||
-> 停止等待用户确认
|
||||
|
||||
data_agent_confirm_generation_plan
|
||||
-> confirmed_plan_id
|
||||
-> 允许生成 draft 和转换 records
|
||||
```
|
||||
|
||||
## 8. 预算、取消和 max_turns
|
||||
|
||||
基座会在模型调用前后、工具请求前检查预算:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:592 initial_budget = self._check_budget(...)
|
||||
src/agent_runtime.py:732 budget_after_model = self._check_budget(...)
|
||||
src/agent_runtime.py:1014 budget_after_tool_request = self._check_budget(...)
|
||||
```
|
||||
|
||||
如果达到最大轮次:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:1440 _build_max_turns_output(...)
|
||||
```
|
||||
|
||||
输出会包含最后一次阶段说明,提醒用户可以继续补充指令。
|
||||
|
||||
取消由后端 run manager 和 tool process registry 处理。Web 点停止后,后端将 run 标记取消,并让工具执行上下文感知 cancel_event。
|
||||
|
||||
## 9. 事件流和前端活动区
|
||||
|
||||
Agent loop 内会不断追加 `stream_events`,后端用 `event_sink` 把事件推给前端。
|
||||
|
||||
后端关键代码:
|
||||
|
||||
```text
|
||||
backend/api/server.py:1751 emit_agent_event(event)
|
||||
backend/api/server.py:1756 state.run_manager.record_event(...)
|
||||
backend/api/server.py:1758 state.run_state_store.record_event(...)
|
||||
backend/api/server.py:2034 StreamingResponse(..., media_type='application/x-ndjson')
|
||||
```
|
||||
|
||||
前端活动区展示的阶段说明、工具开始、工具完成、最终文本,本质上都来自这些 runtime events 或 session replay。
|
||||
@@ -0,0 +1,298 @@
|
||||
# 03. 工具体系和 Tool Handler
|
||||
|
||||

|
||||
|
||||
## 1. 工具体系的职责
|
||||
|
||||
Tool 是执行层。模型只能“请求调用工具”,不能直接执行工具。
|
||||
后端根据工具名找到 handler,校验参数,执行动作,并把结果写回 session。
|
||||
|
||||
工具适合承载:
|
||||
|
||||
- 稳定文件读写。
|
||||
- Python 执行。
|
||||
- Python 包安装。
|
||||
- 数据格式转换和校验。
|
||||
- review 状态机。
|
||||
- 外部系统访问。
|
||||
- 需要权限、取消、路径约束或审计的动作。
|
||||
|
||||
## 2. Tool registry 构成
|
||||
|
||||
入口:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:105 default_tool_registry()
|
||||
```
|
||||
|
||||
它会合并多类工具:
|
||||
|
||||
```text
|
||||
build_file_tools(...)
|
||||
build_execution_tools(...)
|
||||
LSP / web_fetch / search / account / config / task / team / workflow 等
|
||||
Skill 工具
|
||||
data_agent 工具
|
||||
```
|
||||
|
||||
关键片段:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:107 build_file_tools
|
||||
src/agent_tools.py:116 build_execution_tools
|
||||
src/agent_tools.py:1012 AgentTool(name='Skill')
|
||||
src/agent_tools.py:1033 build_data_agent_tools
|
||||
```
|
||||
|
||||
返回结果是:
|
||||
|
||||
```python
|
||||
return {tool.name: tool for tool in tools}
|
||||
```
|
||||
|
||||
## 3. Tool spec 注入模型
|
||||
|
||||
在 Agent loop 中:
|
||||
|
||||
```text
|
||||
src/agent_runtime.py:552
|
||||
tool_specs = [tool.to_openai_tool() for tool in self.tool_registry.values()]
|
||||
```
|
||||
|
||||
每个工具包含:
|
||||
|
||||
```text
|
||||
name
|
||||
description
|
||||
parameters JSON schema
|
||||
handler
|
||||
```
|
||||
|
||||
模型看到的是 name、description、parameters。handler 不暴露给模型,只在后端执行。
|
||||
|
||||
## 4. Tool handler 执行路径
|
||||
|
||||
工具执行入口:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:60 execute_tool(...)
|
||||
src/agent_tools.py:76 execute_tool_streaming(...)
|
||||
```
|
||||
|
||||
执行逻辑:
|
||||
|
||||
```text
|
||||
1. 从 tool_registry 取 tool。
|
||||
2. 找不到则返回 Unknown tool。
|
||||
3. bash 走 streaming。
|
||||
4. 其他工具调用 tool.execute(arguments, context)。
|
||||
5. 工具结果序列化回模型和前端。
|
||||
```
|
||||
|
||||
## 5. 文件工具
|
||||
|
||||
定义位置:
|
||||
|
||||
```text
|
||||
src/agent_tool_specs/files.py
|
||||
```
|
||||
|
||||
主要工具:
|
||||
|
||||
- `list_dir`
|
||||
- `read_file`
|
||||
- `write_file`
|
||||
- `edit_file`
|
||||
- `notebook_edit`
|
||||
- `glob_search`
|
||||
- `grep_search`
|
||||
|
||||
### 5.1 `write_file` 的边界
|
||||
|
||||
`write_file` 当前明确定位为“小文件工具”:
|
||||
|
||||
```text
|
||||
src/agent_tool_specs/files.py
|
||||
Write or append a SMALL UTF-8 file inside the workspace.
|
||||
```
|
||||
|
||||
适合:
|
||||
|
||||
- 短 Markdown。
|
||||
- 少量配置。
|
||||
- 小 JSON。
|
||||
- 少量 JSONL。
|
||||
- 小 CSV。
|
||||
|
||||
不适合:
|
||||
|
||||
- 长 Python 脚本。
|
||||
- 大 JSON。
|
||||
- JSONL 数据集。
|
||||
- 长 CSV。
|
||||
- 大段包含引号和换行的内容。
|
||||
|
||||
原因是模型生成工具参数时,需要把内容嵌入 JSON 参数。长文本、引号、换行会显著增加非法 JSON 参数概率。
|
||||
|
||||
因此系统提示词也要求:
|
||||
|
||||
```text
|
||||
复杂写文件优先用 python_exec 通过 pathlib/json/csv 写入。
|
||||
```
|
||||
|
||||
## 6. Python 执行工具
|
||||
|
||||
定义位置:
|
||||
|
||||
```text
|
||||
src/agent_tool_specs/execution.py
|
||||
```
|
||||
|
||||
主要工具:
|
||||
|
||||
- `python_exec`
|
||||
- `python_package`
|
||||
- `bash`
|
||||
- `sleep`
|
||||
|
||||
### 6.1 `python_exec`
|
||||
|
||||
定位:
|
||||
|
||||
```text
|
||||
结构化文件分析、JSON/JSONL 处理、批量校验、数据抽样、快速计算。
|
||||
```
|
||||
|
||||
支持两种模式:
|
||||
|
||||
```text
|
||||
code
|
||||
一次性 Python 代码。
|
||||
|
||||
script_path
|
||||
调用项目或 Skill 内已有脚本。
|
||||
```
|
||||
|
||||
重要约束:
|
||||
|
||||
- 不用 `bash python ...`。
|
||||
- 不在 `python_exec.code` 里用 subprocess 二次调用 Python 脚本。
|
||||
- 临时文件写入 `PYTHON_EXEC_SCRATCHPAD`。
|
||||
- 交付产物写入 session/output。
|
||||
|
||||
### 6.2 `python_package`
|
||||
|
||||
定位:
|
||||
|
||||
```text
|
||||
给当前用户独立 Python venv 安装缺失包。
|
||||
```
|
||||
|
||||
典型场景:
|
||||
|
||||
- `pandas`
|
||||
- `pyarrow`
|
||||
- `openpyxl`
|
||||
- `elasticsearch`
|
||||
- `urllib3`
|
||||
|
||||
设计上避免安装到项目 `.venv` 或系统 Python。
|
||||
|
||||
### 6.3 `bash`
|
||||
|
||||
`bash` 是兜底工具,不是默认 Python 执行方式。
|
||||
|
||||
适合:
|
||||
|
||||
- git 只读检查。
|
||||
- 系统命令。
|
||||
- 进程控制。
|
||||
- 用户确认后的依赖安装或服务管理。
|
||||
|
||||
不适合:
|
||||
|
||||
- Python 数据分析。
|
||||
- JSON/CSV 转换。
|
||||
- 包安装。
|
||||
|
||||
## 7. 路径解析和 session 路由
|
||||
|
||||
关键实现:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1589 _data_agent_output_path(...)
|
||||
src/agent_tools.py:1624 _data_agent_session_output_root(...)
|
||||
src/agent_tools.py:1630 _resolve_path(...)
|
||||
src/agent_tools.py:1658 _session_logical_path(...)
|
||||
src/agent_tools.py:1685 _execution_cwd(...)
|
||||
```
|
||||
|
||||
逻辑路径会被映射到当前 session:
|
||||
|
||||
```text
|
||||
output/... -> session/output/...
|
||||
outputs/... -> session/output/...
|
||||
scratchpad/... -> session/scratchpad/...
|
||||
scratch/... -> session/scratchpad/...
|
||||
input/... -> session/input/...
|
||||
inputs/... -> session/input/...
|
||||
```
|
||||
|
||||
`python_exec` 的执行 cwd 优先是当前会话 scratchpad:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1685 _execution_cwd(...)
|
||||
```
|
||||
|
||||
## 8. data_agent 工具
|
||||
|
||||
声明位置:
|
||||
|
||||
```text
|
||||
src/agent_tool_specs/data_agent.py
|
||||
```
|
||||
|
||||
handler 注册位置:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1033 build_data_agent_tools(...)
|
||||
```
|
||||
|
||||
主要工具分两类:
|
||||
|
||||
### 8.1 前链路和 review 状态机
|
||||
|
||||
- `data_agent_load_input_sources`
|
||||
- `data_agent_render_source_context`
|
||||
- `data_agent_extract_case_evidence`
|
||||
- `data_agent_prepare_generation_goal`
|
||||
- `data_agent_confirm_generation_goal`
|
||||
- `data_agent_prepare_generation_plan`
|
||||
- `data_agent_show_generation_plan`
|
||||
- `data_agent_update_generation_plan`
|
||||
- `data_agent_confirm_generation_plan`
|
||||
|
||||
这类工具当前仍属于平台工具,因为它们维护 pending/confirmed 状态,以及产品数据生成的 review 门禁。
|
||||
|
||||
### 8.2 历史格式转换工具
|
||||
|
||||
- `data_agent_normalize_dataset_draft`
|
||||
- `data_agent_validate_dataset_records`
|
||||
- `data_agent_export_dataset_records`
|
||||
- `data_agent_export_training_jsonl`
|
||||
- `data_agent_export_planning_eval_csv`
|
||||
|
||||
这部分能力已经逐步迁移到 `skills/product-data/scripts/`,平台工具更多是历史兼容和适配层。
|
||||
|
||||
## 9. 工具设计原则
|
||||
|
||||
当前工具体系的技术取舍:
|
||||
|
||||
```text
|
||||
模型负责决策。
|
||||
工具负责执行。
|
||||
Skill 负责流程经验。
|
||||
脚本负责可迁移确定性能力。
|
||||
```
|
||||
|
||||
工具描述要足够明确,否则模型会选错工具;参数 schema 要尽量简单,否则不同模型后端可能不兼容。
|
||||
@@ -0,0 +1,256 @@
|
||||
# 04. Skill 体系和能力包约定
|
||||
|
||||

|
||||
|
||||
## 1. Skill 的定位
|
||||
|
||||
Skill 是经验层。它不是单纯 prompt,也不是单纯脚本。
|
||||
|
||||
一个 Skill 应该回答:
|
||||
|
||||
- 什么场景触发。
|
||||
- 输入材料是什么。
|
||||
- Agent 应该按什么流程做。
|
||||
- 哪些地方必须让用户 review。
|
||||
- 应该调用哪些工具或脚本。
|
||||
- 产物应该写到哪里。
|
||||
- 哪些做法是禁止的。
|
||||
|
||||
稳定可执行逻辑不应该长期写在 Skill 文本里,而应该进入:
|
||||
|
||||
```text
|
||||
skills/<skill-name>/scripts/
|
||||
```
|
||||
|
||||
或者平台级工具。
|
||||
|
||||
## 2. Skill loader 实现
|
||||
|
||||
关键文件:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py
|
||||
```
|
||||
|
||||
项目级 Skill 目录:
|
||||
|
||||
```text
|
||||
skills/<skill-name>/SKILL.md
|
||||
```
|
||||
|
||||
核心数据结构:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py:28 BundledSkill
|
||||
```
|
||||
|
||||
字段:
|
||||
|
||||
```text
|
||||
name
|
||||
description
|
||||
when_to_use
|
||||
aliases
|
||||
allowed_tools
|
||||
user_invocable
|
||||
source
|
||||
path
|
||||
get_prompt
|
||||
```
|
||||
|
||||
## 3. SKILL.md 解析
|
||||
|
||||
解析逻辑:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py:147 _parse_front_matter
|
||||
src/bundled_skills.py:176 _load_directory_skill
|
||||
```
|
||||
|
||||
`SKILL.md` 必须有 frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: product-data
|
||||
description: 从产品/标签定义、手写边界规则或示例 query 中提取标签边界...
|
||||
when_to_use: 当用户提供产品定义、标签规则...
|
||||
aliases: definition-data, label-data
|
||||
allowed_tools: read_file, write_file, python_exec
|
||||
---
|
||||
```
|
||||
|
||||
解析后:
|
||||
|
||||
- frontmatter 进入 `BundledSkill` 元数据。
|
||||
- body 作为真正的 Skill prompt。
|
||||
- 如果调用 Skill 时带 args,会追加到 `## Invocation Arguments`。
|
||||
|
||||
对应实现:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py:138 _directory_skill_prompt
|
||||
```
|
||||
|
||||
## 4. Skill 发现顺序
|
||||
|
||||
项目 Skill 发现入口:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py:199 load_directory_skills
|
||||
src/bundled_skills.py:215 load_project_skills
|
||||
```
|
||||
|
||||
系统提示词中可见 Skill 列表由:
|
||||
|
||||
```text
|
||||
src/bundled_skills.py:270 format_skills_for_system_prompt
|
||||
```
|
||||
|
||||
生成。
|
||||
|
||||
Web 后端会按当前账号和 session 配置计算启用 Skill:
|
||||
|
||||
```text
|
||||
backend/api/server.py:691 enabled_skill_names
|
||||
backend/api/server.py:706 set_skill_enabled
|
||||
backend/api/server.py:738 set_all_skills_enabled
|
||||
```
|
||||
|
||||
这意味着:
|
||||
|
||||
- Skill 可以存在于项目中,但不一定对某个 session 启用。
|
||||
- 启用状态影响系统提示词里的 Skill 列表。
|
||||
- 被禁用的 Skill 不应该被模型主动选择。
|
||||
|
||||
## 5. Skill 工具
|
||||
|
||||
Skill 本身也是一个工具:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1012 AgentTool(name='Skill')
|
||||
```
|
||||
|
||||
模型调用:
|
||||
|
||||
```json
|
||||
{
|
||||
"skill": "product-data",
|
||||
"args": "用户原始需求或显式参数"
|
||||
}
|
||||
```
|
||||
|
||||
执行后,Skill body 会被加入对话,让模型按 Skill 中的流程继续做任务。
|
||||
|
||||
## 6. Skill 和 Agent Loop 的关系
|
||||
|
||||
Skill 不会替代 Agent loop,而是改变 Agent loop 的下一步决策依据。
|
||||
|
||||
典型模式:
|
||||
|
||||
```text
|
||||
用户提出任务
|
||||
-> 模型从 Skill 列表中选择某个 Skill
|
||||
-> 调用 Skill 工具
|
||||
-> Skill.md 正文进入上下文
|
||||
-> 模型按 Skill 指令调用 read_file/python_exec/data_agent 等工具
|
||||
-> 工具结果进入上下文
|
||||
-> 模型继续按 Skill 流程推进
|
||||
```
|
||||
|
||||
因此 Skill 的好坏直接影响:
|
||||
|
||||
- 模型能否召回正确能力。
|
||||
- 是否会过早执行。
|
||||
- 是否能在 review 门禁停下来。
|
||||
- 是否能使用正确工具而不是手写不稳定逻辑。
|
||||
|
||||
## 7. 推荐 Skill 目录结构
|
||||
|
||||
```text
|
||||
skills/<skill-name>/
|
||||
SKILL.md
|
||||
README.md
|
||||
knowledge/
|
||||
scripts/
|
||||
examples/
|
||||
schemas/
|
||||
tools.yaml
|
||||
requirements.txt
|
||||
```
|
||||
|
||||
各部分职责:
|
||||
|
||||
```text
|
||||
SKILL.md
|
||||
运行时入口,写流程、门禁、工具调用方式和禁止事项。
|
||||
|
||||
README.md
|
||||
给维护者看的说明,不一定进入模型上下文。
|
||||
|
||||
knowledge/
|
||||
业务知识、标签规则、字段说明、边界案例。
|
||||
|
||||
scripts/
|
||||
确定性脚本,优先通过 python_exec.script_path 执行。
|
||||
|
||||
examples/
|
||||
示例输入输出,用于回归和讲解。
|
||||
|
||||
schemas/
|
||||
JSON schema 或字段约定。
|
||||
|
||||
tools.yaml
|
||||
描述 portable scripts 如何注册为工具,便于迁移到其他 Agent。
|
||||
|
||||
requirements.txt
|
||||
Skill 脚本的 Python 依赖。
|
||||
```
|
||||
|
||||
## 8. Skill 更新
|
||||
|
||||
Web 后端提供 Skill 更新能力:
|
||||
|
||||
```text
|
||||
backend/api/server.py:765 sync_skills_from_git
|
||||
```
|
||||
|
||||
核心行为:
|
||||
|
||||
```text
|
||||
1. 检查当前目录是否是 git 仓库。
|
||||
2. 检查 tracked 文件是否干净。
|
||||
3. git fetch origin。
|
||||
4. git pull --ff-only origin 当前分支。
|
||||
5. 清理当前账号 agent cache。
|
||||
6. 重新读取 get_bundled_skills。
|
||||
```
|
||||
|
||||
这让新增或修改 Skill 后,不一定需要重启服务才能让 Skill 列表刷新。
|
||||
|
||||
## 9. Skill 设计边界
|
||||
|
||||
适合写在 Skill:
|
||||
|
||||
- 工作流。
|
||||
- 何时提问。
|
||||
- 何时 review。
|
||||
- 哪些工具优先。
|
||||
- 输出位置约定。
|
||||
- 常见失败经验。
|
||||
|
||||
不适合长期写在 Skill:
|
||||
|
||||
- 大段可检索知识。
|
||||
- 复杂代码。
|
||||
- 格式转换。
|
||||
- 查询外部系统的具体实现。
|
||||
- 需要校验的稳定数据结构。
|
||||
|
||||
这些应该分别放到:
|
||||
|
||||
```text
|
||||
knowledge/
|
||||
scripts/
|
||||
schemas/
|
||||
platform tools
|
||||
```
|
||||
@@ -0,0 +1,243 @@
|
||||
# 05. 会话工作区、运行态和记忆
|
||||
|
||||

|
||||
|
||||
## 1. 会话工作区
|
||||
|
||||
每个用户、每个会话都有独立目录:
|
||||
|
||||
```text
|
||||
.port_sessions/accounts/<account_id>/sessions/<session_id>/
|
||||
input/
|
||||
scratchpad/
|
||||
output/
|
||||
session.json
|
||||
```
|
||||
|
||||
目录职责:
|
||||
|
||||
```text
|
||||
input/
|
||||
用户上传或明确提供的输入资料。
|
||||
|
||||
scratchpad/
|
||||
临时脚本、中间文件、抽样缓存、断点记录。
|
||||
|
||||
output/
|
||||
最终交付产物。
|
||||
|
||||
session.json
|
||||
会话消息、工具调用、usage、events、file_history、runtime metadata。
|
||||
```
|
||||
|
||||
## 2. 工作区路径路由
|
||||
|
||||
路径解析实现:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1658 _session_logical_path
|
||||
```
|
||||
|
||||
逻辑路径:
|
||||
|
||||
```text
|
||||
output/... -> session/output/...
|
||||
outputs/... -> session/output/...
|
||||
scratchpad/... -> session/scratchpad/...
|
||||
scratch/... -> session/scratchpad/...
|
||||
input/... -> session/input/...
|
||||
inputs/... -> session/input/...
|
||||
```
|
||||
|
||||
Python 执行 cwd:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1685 _execution_cwd
|
||||
```
|
||||
|
||||
优先使用当前 session scratchpad。这是为了避免临时脚本和缓存污染项目根目录。
|
||||
|
||||
## 3. 平台代码写保护
|
||||
|
||||
相关实现:
|
||||
|
||||
```text
|
||||
src/agent_tools.py:1118 _PLATFORM_READONLY_DIRS
|
||||
src/agent_tools.py:1698 _is_platform_code_path
|
||||
src/agent_tools.py:1708 _ensure_not_platform_code_write
|
||||
```
|
||||
|
||||
当前平台目录:
|
||||
|
||||
```text
|
||||
src
|
||||
backend
|
||||
frontend
|
||||
scripts
|
||||
```
|
||||
|
||||
在数据 Agent 会话中默认视为只读。除非用户明确进入平台开发任务,否则业务任务不应修改平台代码。
|
||||
|
||||
## 4. Run 状态和活动区
|
||||
|
||||
后端在 `/api/chat` 运行时创建 run record:
|
||||
|
||||
```text
|
||||
backend/api/server.py:1720 run_record = state.run_manager.start(...)
|
||||
backend/api/server.py:1722 state.run_state_store.start(...)
|
||||
```
|
||||
|
||||
运行事件通过 `emit_agent_event` 记录:
|
||||
|
||||
```text
|
||||
backend/api/server.py:1751 emit_agent_event
|
||||
backend/api/server.py:1756 run_manager.record_event
|
||||
backend/api/server.py:1758 run_state_store.record_event
|
||||
```
|
||||
|
||||
返回前端:
|
||||
|
||||
```text
|
||||
backend/api/server.py:2034 StreamingResponse
|
||||
```
|
||||
|
||||
前端活动区看到的内容主要来自:
|
||||
|
||||
- `run_started`
|
||||
- `tool_start`
|
||||
- `tool_result`
|
||||
- 模型阶段说明
|
||||
- final text stream events
|
||||
- run finish/error/cancel 状态
|
||||
|
||||
## 5. 会话持久化
|
||||
|
||||
运行结束后,后端序列化结果:
|
||||
|
||||
```text
|
||||
backend/api/server.py:2056 _serialize_run_result
|
||||
backend/api/server.py:2069 _normalize_transcript_entry
|
||||
```
|
||||
|
||||
会话读取:
|
||||
|
||||
```text
|
||||
backend/api/server.py:2094 _serialize_stored_session
|
||||
```
|
||||
|
||||
`agent_runtime` 在多个结束路径都会调用:
|
||||
|
||||
```text
|
||||
_persist_session(session, result)
|
||||
```
|
||||
|
||||
这让刷新后可以恢复:
|
||||
|
||||
- 用户消息。
|
||||
- assistant 文本。
|
||||
- tool_calls。
|
||||
- tool result。
|
||||
- elapsed。
|
||||
- file_history。
|
||||
|
||||
## 6. 记忆体系
|
||||
|
||||
实现位置:
|
||||
|
||||
```text
|
||||
src/personal_memory.py
|
||||
```
|
||||
|
||||
### 6.1 文件和数据库
|
||||
|
||||
```text
|
||||
memory.db
|
||||
user.md
|
||||
skills/<skill-name>.md
|
||||
```
|
||||
|
||||
常量:
|
||||
|
||||
```text
|
||||
src/personal_memory.py:26 MEMORY_DB_FILENAME
|
||||
src/personal_memory.py:27 USER_MEMORY_FILENAME
|
||||
src/personal_memory.py:28 SKILL_MEMORY_DIRNAME
|
||||
```
|
||||
|
||||
### 6.2 注入逻辑
|
||||
|
||||
```text
|
||||
src/personal_memory.py:102 render_injection
|
||||
```
|
||||
|
||||
注入规则:
|
||||
|
||||
```text
|
||||
1. 读取 user.md。
|
||||
2. 根据 enabled_skill_names 读取对应 skills/<skill>.md。
|
||||
3. 拼成 # 个性化记忆。
|
||||
4. 如果用户本轮要求冲突,以本轮要求为准。
|
||||
```
|
||||
|
||||
后端调用:
|
||||
|
||||
```text
|
||||
backend/api/server.py:1739 memory_manager.render_injection(...)
|
||||
```
|
||||
|
||||
### 6.3 入队逻辑
|
||||
|
||||
运行结束后:
|
||||
|
||||
```text
|
||||
backend/api/server.py:1920 memory_manager.enqueue_interaction(...)
|
||||
```
|
||||
|
||||
记忆模块内:
|
||||
|
||||
```text
|
||||
src/personal_memory.py:138 enqueue_interaction
|
||||
src/personal_memory.py:635 detect_memory_signals
|
||||
```
|
||||
|
||||
会检测:
|
||||
|
||||
- 显式记忆词:记住、以后、下次、默认、总是、不要、应该、固定。
|
||||
- 纠错词:不对、不是这样、格式错、之前说过、还是不行。
|
||||
- Skill/工具/流程/格式相关表述。
|
||||
- 工具参数非法 JSON 等工具经验。
|
||||
|
||||
### 6.4 后台整理
|
||||
|
||||
核心逻辑:
|
||||
|
||||
```text
|
||||
src/personal_memory.py:378 _consolidate_events
|
||||
src/personal_memory.py:419 _generate_memory_updates
|
||||
src/personal_memory.py:471 _fallback_memory_updates
|
||||
```
|
||||
|
||||
设计取舍:
|
||||
|
||||
- 主链路不直接生成记忆。
|
||||
- 事件先进入 SQLite 队列。
|
||||
- 后台 worker 批量整理。
|
||||
- LLM 失败时有 fallback 规则。
|
||||
- Markdown 是最终可编辑记忆正文。
|
||||
|
||||
## 7. 可观测性设计
|
||||
|
||||
当前可观测性来自三个层次:
|
||||
|
||||
```text
|
||||
运行态
|
||||
run_manager + run_state_store,支持运行中刷新、停止、恢复活动区。
|
||||
|
||||
会话态
|
||||
session.json,保存完整消息和工具调用。
|
||||
|
||||
产物态
|
||||
session/input、scratchpad、output,文件面板可查看和下载。
|
||||
```
|
||||
|
||||
这个设计让用户不仅看到最终回复,也能看到 Agent 做了什么、文件在哪里、失败在哪个工具或阶段。
|
||||
@@ -0,0 +1,292 @@
|
||||
# 06. product-data Skill 实现
|
||||
|
||||

|
||||
|
||||
## 1. 定位
|
||||
|
||||
`product-data` 是数据开发链路的核心 Skill,负责:
|
||||
|
||||
```text
|
||||
产品定义 / 标签规则 / 手写边界 / 示例 query / badcase
|
||||
-> 输入文本化
|
||||
-> generation goal
|
||||
-> 用户 review
|
||||
-> generation plan
|
||||
-> 用户确认数量、标签、边界、路径
|
||||
-> dataset draft text
|
||||
-> canonical records
|
||||
-> validate
|
||||
-> export records / table / training / eval
|
||||
```
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/product-data/SKILL.md
|
||||
skills/product-data/knowledge/
|
||||
skills/product-data/scripts/
|
||||
```
|
||||
|
||||
## 2. Skill 目录结构
|
||||
|
||||
当前 `SKILL.md` 中定义的能力组织:
|
||||
|
||||
```text
|
||||
skills/product-data/
|
||||
SKILL.md
|
||||
tools.yaml
|
||||
requirements.txt
|
||||
knowledge/
|
||||
dataset_draft_v1.md
|
||||
canonical_record_v1.md
|
||||
portable_skill_contract.md
|
||||
schemas/
|
||||
scripts/
|
||||
normalize_dataset_draft.py
|
||||
validate_dataset_records.py
|
||||
export_dataset_records.py
|
||||
export_dataset_table.py
|
||||
export_training_jsonl.py
|
||||
export_planning_eval_csv.py
|
||||
```
|
||||
|
||||
分工:
|
||||
|
||||
```text
|
||||
SKILL.md
|
||||
流程协议、门禁、工具调用顺序、禁止事项。
|
||||
|
||||
knowledge/
|
||||
数据草稿、canonical record 和 portable skill contract。
|
||||
|
||||
scripts/
|
||||
确定性转换、校验和导出。
|
||||
|
||||
data_agent_* 平台工具
|
||||
负责输入文本化和 review 状态机。
|
||||
```
|
||||
|
||||
## 3. 输入类型
|
||||
|
||||
Skill 将输入分成三类:
|
||||
|
||||
```text
|
||||
文件定义型
|
||||
产品定义、标签定义、路由规则、表格、Markdown、CSV。
|
||||
|
||||
手写规则型
|
||||
用户直接描述边界,例如“找附近美食给餐饮服务,导航去某地给地图导航”。
|
||||
|
||||
示例归纳型
|
||||
用户只给 query/example/badcase,需要先归纳边界和标签倾向。
|
||||
```
|
||||
|
||||
三类输入最后统一整理成:
|
||||
|
||||
```text
|
||||
dataset_label
|
||||
target / target_definitions
|
||||
plan_hint
|
||||
coverage
|
||||
exclusions
|
||||
open_questions
|
||||
source_refs
|
||||
complex 规则
|
||||
```
|
||||
|
||||
这一步称为 `generation_goal`。
|
||||
|
||||
## 4. Review 门禁
|
||||
|
||||
`product-data` 有两个门禁模式。
|
||||
|
||||
### 4.1 一次确认模式
|
||||
|
||||
适用:
|
||||
|
||||
- 用户直接给出清晰手写规则。
|
||||
- target 表达明确。
|
||||
- 用户已经希望生成数据。
|
||||
|
||||
链路:
|
||||
|
||||
```text
|
||||
data_agent_prepare_generation_plan(direct_review=true)
|
||||
-> 展示目标 + 数量 + 路径
|
||||
-> 等待“确认,开始生成”
|
||||
```
|
||||
|
||||
### 4.2 两段确认模式
|
||||
|
||||
适用:
|
||||
|
||||
- 用户提供文件、表格、badcase、长文档。
|
||||
- 标签、边界、字段有歧义。
|
||||
- 需要先从资料中抽取 generation goal。
|
||||
|
||||
链路:
|
||||
|
||||
```text
|
||||
data_agent_load_input_sources
|
||||
-> data_agent_render_source_context
|
||||
-> Agent 整理 generation_goal
|
||||
-> data_agent_prepare_generation_goal
|
||||
-> 用户确认目标
|
||||
-> data_agent_confirm_generation_goal
|
||||
-> data_agent_prepare_generation_plan
|
||||
-> 用户确认计划
|
||||
-> data_agent_confirm_generation_plan
|
||||
```
|
||||
|
||||
## 5. 和 Agent Loop 的关系
|
||||
|
||||
`product-data` 明确利用 Agent loop 做分阶段控制。
|
||||
|
||||
```text
|
||||
第一轮:
|
||||
模型选择 product-data
|
||||
调输入工具
|
||||
调 prepare_generation_goal 或 prepare_generation_plan
|
||||
输出 review 信息
|
||||
停止
|
||||
|
||||
第二轮:
|
||||
用户确认目标或计划
|
||||
Agent resume session
|
||||
调 confirm 工具
|
||||
继续下一阶段
|
||||
|
||||
第三轮:
|
||||
用户确认计划
|
||||
Agent 生成 dataset draft
|
||||
每批调用 normalize 脚本
|
||||
调 validate 脚本
|
||||
调 export 脚本
|
||||
输出最终文件路径
|
||||
```
|
||||
|
||||
重点是:确认状态不是靠自由文本记忆,而是由工具维护 `confirmed_goal_id` 和 `confirmed_plan_id`。
|
||||
|
||||
## 6. 数据格式设计
|
||||
|
||||
### 6.1 dataset draft text
|
||||
|
||||
面向模型生成,要求模型用较低结构负担描述:
|
||||
|
||||
- 用户 / 小爱 对话。
|
||||
- 当前 query。
|
||||
- target。
|
||||
- complex。
|
||||
- 场景说明。
|
||||
|
||||
设计目标是降低模型直接写 JSONL 的难度。
|
||||
|
||||
### 6.2 canonical record
|
||||
|
||||
面向工具处理,字段稳定。
|
||||
|
||||
用于:
|
||||
|
||||
- 校验结构。
|
||||
- 导出流转 CSV。
|
||||
- 导出训练 JSONL。
|
||||
- 导出评测 planningPrompt CSV。
|
||||
|
||||
### 6.3 complex 独立维度
|
||||
|
||||
`complex` 不属于 target。
|
||||
|
||||
内部保存:
|
||||
|
||||
```text
|
||||
complex: false
|
||||
target: Agent(tag="地图导航")
|
||||
```
|
||||
|
||||
训练输出组合:
|
||||
|
||||
```text
|
||||
complex=false
|
||||
Agent(tag="地图导航")
|
||||
```
|
||||
|
||||
评测 CSV 里:
|
||||
|
||||
```text
|
||||
code标签: Agent(tag="地图导航")
|
||||
complex: FALSE
|
||||
```
|
||||
|
||||
## 7. 脚本链路
|
||||
|
||||
生成式数据确认后,Skill 要求使用 `python_exec.script_path` 调脚本。
|
||||
|
||||
典型顺序:
|
||||
|
||||
```text
|
||||
normalize_dataset_draft.py
|
||||
输入 draft + confirmed_plan_id
|
||||
输出/追加 scratchpad/normalized_records.jsonl
|
||||
|
||||
validate_dataset_records.py
|
||||
读取 normalized_records.jsonl
|
||||
校验字段、target、complex、时间戳、多轮上下文
|
||||
|
||||
export_dataset_records.py
|
||||
导出 output/records.jsonl
|
||||
同时生成 output/records.csv
|
||||
|
||||
export_training_jsonl.py
|
||||
导出 output/training.jsonl
|
||||
|
||||
export_planning_eval_csv.py
|
||||
导出 output/eval_planning.csv
|
||||
```
|
||||
|
||||
为什么不用 `write_file`:
|
||||
|
||||
- records、CSV、JSONL 都是强格式数据。
|
||||
- 模型手写容易出错。
|
||||
- 脚本能统一 timestamp、prev_session、context、complex/target 组合。
|
||||
|
||||
## 8. 输出约束
|
||||
|
||||
固定逻辑输出:
|
||||
|
||||
```text
|
||||
output/records.jsonl
|
||||
output/records.csv
|
||||
output/training.jsonl
|
||||
output/eval_planning.csv
|
||||
```
|
||||
|
||||
通过路径路由,实际写入:
|
||||
|
||||
```text
|
||||
.port_sessions/accounts/<account>/sessions/<session>/output/
|
||||
```
|
||||
|
||||
Skill 明确禁止:
|
||||
|
||||
- 按数据集名创建随机子目录。
|
||||
- 把 records 写到项目根目录。
|
||||
- 用 `write_file` 手写最终 JSONL/CSV。
|
||||
- 在未确认 plan 前生成数据。
|
||||
|
||||
## 9. 设计边界
|
||||
|
||||
`product-data` 负责:
|
||||
|
||||
- 数据目标对齐。
|
||||
- 生成计划 review。
|
||||
- dataset draft 生成协议。
|
||||
- canonical records 转换和导出。
|
||||
|
||||
不负责:
|
||||
|
||||
- 判断所有标签知识。
|
||||
- 查询线上数据。
|
||||
- ELK 检索。
|
||||
- 模型训练或 git 数据仓库提交。
|
||||
|
||||
标签知识应由 `label-master` 辅助,线上数据由 `online-mining-v2` 或相关 Skill 获取。
|
||||
@@ -0,0 +1,177 @@
|
||||
# 07. online-mining-v2 Skill 实现
|
||||
|
||||

|
||||
|
||||
## 1. 定位
|
||||
|
||||
`online-mining-v2` 用于从线上 ELK 日志中挖掘 case,并把候选样本转换成 `product-data` 兼容的标准数据。
|
||||
|
||||
典型链路:
|
||||
|
||||
```text
|
||||
线上挖掘需求
|
||||
-> 明确目标标签、complex、筛选特征
|
||||
-> 探索 ELK 表字段
|
||||
-> 搜索候选
|
||||
-> 抽样 review
|
||||
-> 调整策略
|
||||
-> 直接转 canonical records
|
||||
-> 或转 product-data 生成补数
|
||||
```
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/online-mining-v2/SKILL.md
|
||||
skills/online-mining-v2/knowledge/
|
||||
skills/online-mining-v2/scripts/
|
||||
```
|
||||
|
||||
## 2. 能力组织
|
||||
|
||||
`online-mining-v2` 不新增平台注册工具。它把能力放在 Skill 目录下,通过 `python_exec.script_path` 执行。
|
||||
|
||||
```text
|
||||
scripts/
|
||||
online_mining_common.py
|
||||
elk_profile_index.py
|
||||
elk_search_cases.py
|
||||
elk_fetch_by_request_ids.py
|
||||
elk_join_request_logs.py
|
||||
build_dataset_draft.py
|
||||
build_online_records.py
|
||||
```
|
||||
|
||||
这样做的原因:
|
||||
|
||||
- ELK 查询逻辑属于该 Skill 的业务能力。
|
||||
- 迁移到其他 Agent 时可以直接跑脚本。
|
||||
- 平台只需要提供通用 `python_exec` 和 `python_package`。
|
||||
|
||||
## 3. 默认数据源
|
||||
|
||||
当前重点支持两类索引:
|
||||
|
||||
```text
|
||||
pre-processing*
|
||||
前处理日志。
|
||||
适合拿模型 prompt、模型输出、候选 domain、excellent_domains_result。
|
||||
|
||||
arch-flat-nlp-log-f-*
|
||||
主 NLP 日志。
|
||||
适合拿 query、domain、func、request_id、device_id、device、tts/text/to_speak。
|
||||
```
|
||||
|
||||
Skill 文档中会引导 Agent:
|
||||
|
||||
- 先用 `elk_profile_index.py` 看字段和样本。
|
||||
- 再用 `elk_search_cases.py` 根据 query/domain/model output 搜索。
|
||||
- 必要时用 request_id 做双表 join。
|
||||
|
||||
## 4. 和 Agent Loop 的关系
|
||||
|
||||
这个 Skill 的交互不是“一次查询结束”,而是策略迭代:
|
||||
|
||||
```text
|
||||
用户描述需求
|
||||
-> Agent 整理目标标签和筛选特征
|
||||
-> 如缺目标标签或字段,先问用户
|
||||
-> python_exec 调 elk_profile_index.py
|
||||
-> 模型观察字段和样本
|
||||
-> python_exec 调 elk_search_cases.py
|
||||
-> 模型观察候选质量
|
||||
-> 抽样展示给用户 review
|
||||
-> 用户说哪里不对
|
||||
-> 调整 filters / regex / domain / model output 条件
|
||||
-> 再搜索
|
||||
```
|
||||
|
||||
Agent loop 的价值在这里很明显:每次工具结果都会进入上下文,模型可以基于真实候选调整策略。
|
||||
|
||||
## 5. 两条分支
|
||||
|
||||
`online-mining-v2` 最重要的设计是强制区分两个分支。
|
||||
|
||||
### 5.1 直接线上样本分支
|
||||
|
||||
适用:
|
||||
|
||||
```text
|
||||
用户想把线上筛出来的真实 case 作为评测集或专项集。
|
||||
```
|
||||
|
||||
行为:
|
||||
|
||||
```text
|
||||
不生成新 query。
|
||||
不进入 product-data generation plan。
|
||||
用 build_online_records.py 直接转 canonical records。
|
||||
```
|
||||
|
||||
典型输出:
|
||||
|
||||
```text
|
||||
output/records.jsonl
|
||||
output/records.csv
|
||||
```
|
||||
|
||||
### 5.2 补充生成分支
|
||||
|
||||
适用:
|
||||
|
||||
```text
|
||||
用户想围绕线上问题扩写更多类似 case。
|
||||
```
|
||||
|
||||
行为:
|
||||
|
||||
```text
|
||||
先分析线上 badcase。
|
||||
整理错误类型和覆盖目标。
|
||||
再转 product-data 的 generation goal / plan / draft / records 流程。
|
||||
```
|
||||
|
||||
这条边界避免了旧流程里出现的错误:用户只是想“把候选转样本”,Agent 却误走“生成新数据”。
|
||||
|
||||
## 6. 和 product-data 的关系
|
||||
|
||||
`online-mining-v2` 后处理复用 `product-data` 的标准:
|
||||
|
||||
```text
|
||||
canonical record v1
|
||||
records.jsonl
|
||||
records.csv
|
||||
training.jsonl
|
||||
eval_planning.csv
|
||||
```
|
||||
|
||||
复用脚本:
|
||||
|
||||
```text
|
||||
skills/product-data/scripts/normalize_dataset_draft.py
|
||||
skills/product-data/scripts/validate_dataset_records.py
|
||||
skills/product-data/scripts/export_dataset_records.py
|
||||
skills/product-data/scripts/export_training_jsonl.py
|
||||
skills/product-data/scripts/export_planning_eval_csv.py
|
||||
```
|
||||
|
||||
因此线上挖掘和产品定义生成最终可以进入同一套数据格式。
|
||||
|
||||
## 7. 设计边界
|
||||
|
||||
`online-mining-v2` 负责:
|
||||
|
||||
- ELK 字段探索。
|
||||
- ELK 条件搜索。
|
||||
- request_id 补全。
|
||||
- 候选样本 review。
|
||||
- 线上候选转 canonical records。
|
||||
|
||||
不负责:
|
||||
|
||||
- 定义 canonical record 标准。
|
||||
- 生成全新补数。
|
||||
- 判断复杂标签知识。
|
||||
- 训练数据提交。
|
||||
|
||||
这些分别交给 `product-data`、`label-master` 或后续数据仓库 Skill。
|
||||
@@ -0,0 +1,231 @@
|
||||
# 08. label-master Skill 实现
|
||||
|
||||

|
||||
|
||||
## 1. 定位
|
||||
|
||||
`label-master` 是标签知识和边界分析 Skill。
|
||||
|
||||
它不把“给 query 打标签”做成一个黑盒工具,而是让 Agent 逐步读取知识、比较候选、解释依据,并在必要时调用脚本校验最终输出格式。
|
||||
|
||||
典型链路:
|
||||
|
||||
```text
|
||||
query / 标签边界问题 / target 校验需求
|
||||
-> 读取决策流程
|
||||
-> 读取候选召回索引
|
||||
-> 找 2-5 个候选标签
|
||||
-> 读取候选标签卡片
|
||||
-> 命中混淆时读取边界卡
|
||||
-> 判断 complex / 多指令 / 自动任务等结构维度
|
||||
-> 判断输出形态
|
||||
-> 给出推荐、候选、依据、排除项和不确定点
|
||||
-> 如要落数据,调用 validate_label_output.py
|
||||
```
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/label-master/SKILL.md
|
||||
skills/label-master/knowledge/
|
||||
skills/label-master/scripts/
|
||||
```
|
||||
|
||||
## 2. 知识组织
|
||||
|
||||
核心目录:
|
||||
|
||||
```text
|
||||
knowledge/
|
||||
标签总览.md
|
||||
决策流程.md
|
||||
索引/
|
||||
候选召回索引.md
|
||||
标签索引.md
|
||||
维度索引.md
|
||||
label_manifest.json
|
||||
判断维度/
|
||||
复杂度/
|
||||
多指令/
|
||||
自动任务/
|
||||
标注输出形态.md
|
||||
输出能力/
|
||||
标签/
|
||||
边界/
|
||||
边界索引.md
|
||||
高频混淆/
|
||||
领域概览/
|
||||
迁移记录.md
|
||||
```
|
||||
|
||||
设计原则:
|
||||
|
||||
```text
|
||||
索引先行
|
||||
不直接读全量标签卡。
|
||||
|
||||
维度分离
|
||||
complex、多指令、自动任务不是业务标签。
|
||||
|
||||
标签卡片中文维护
|
||||
方便人工编辑。
|
||||
|
||||
输出能力独立
|
||||
function、intent、object、Agent 包装放在输出能力层。
|
||||
|
||||
边界卡优先人工维护
|
||||
高频混淆写清楚,不只依赖自动迁移总结。
|
||||
```
|
||||
|
||||
## 3. Agent 使用方式
|
||||
|
||||
`label-master` 的关键在于利用 Agent 的多轮阅读和规划能力。
|
||||
|
||||
典型 Agent loop:
|
||||
|
||||
```text
|
||||
模型选择 label-master
|
||||
-> read_file knowledge/决策流程.md
|
||||
-> read_file knowledge/索引/候选召回索引.md
|
||||
-> read_file 候选标签卡片
|
||||
-> read_file 高频混淆边界卡
|
||||
-> 必要时 read_file 判断维度/复杂度/*
|
||||
-> 必要时 read_file 输出能力/*
|
||||
-> 输出可 review 判断
|
||||
```
|
||||
|
||||
为什么不做成单个 `classify_query(query) -> label` 工具:
|
||||
|
||||
- 标签判断常常需要比较候选和排除项。
|
||||
- function / intent / Agent 包装要看迁移状态。
|
||||
- complex、多指令、自动任务是独立维度。
|
||||
- 人类 review 需要看到依据,而不是只看到最终标签。
|
||||
|
||||
因此脚本只做索引和校验,不替代语义判断。
|
||||
|
||||
## 4. 输出形态
|
||||
|
||||
标签知识中存在多种输出形态:
|
||||
|
||||
```text
|
||||
Agent(tag="xxx")
|
||||
function program
|
||||
intent
|
||||
object + function 组合
|
||||
多指令 JSON
|
||||
自动任务 JSON
|
||||
complex=true/false
|
||||
```
|
||||
|
||||
`complex` 是独立维度,不应该混在 target 里。
|
||||
|
||||
例如训练输出可以组合成:
|
||||
|
||||
```text
|
||||
complex=false
|
||||
Agent(tag="地图导航")
|
||||
```
|
||||
|
||||
但内部判断要拆成:
|
||||
|
||||
```text
|
||||
complex: false
|
||||
target: Agent(tag="地图导航")
|
||||
```
|
||||
|
||||
## 5. 脚本能力
|
||||
|
||||
### 5.1 build_label_manifest.py
|
||||
|
||||
用途:
|
||||
|
||||
```text
|
||||
把 Markdown 知识生成机器索引。
|
||||
```
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/label-master/scripts/build_label_manifest.py
|
||||
```
|
||||
|
||||
输出:
|
||||
|
||||
```text
|
||||
skills/label-master/knowledge/索引/label_manifest.json
|
||||
```
|
||||
|
||||
使用场景:
|
||||
|
||||
- 新增标签卡。
|
||||
- 修改输出能力。
|
||||
- 修改判断维度。
|
||||
- 修改边界知识。
|
||||
|
||||
### 5.2 validate_label_output.py
|
||||
|
||||
用途:
|
||||
|
||||
```text
|
||||
校验 target/function/intent/Agent/多指令/自动任务输出格式。
|
||||
```
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/label-master/scripts/validate_label_output.py
|
||||
```
|
||||
|
||||
典型调用:
|
||||
|
||||
```text
|
||||
python_exec(script_path="skills/label-master/scripts/validate_label_output.py", args=["--target", "Agent(tag=\"地图导航\")"])
|
||||
```
|
||||
|
||||
批量校验:
|
||||
|
||||
```text
|
||||
--file output/records.jsonl --field target
|
||||
```
|
||||
|
||||
## 6. 和 product-data 的关系
|
||||
|
||||
`product-data` 在需要确认 target 或生成边界数据时,可以读取 `label-master` 的知识。
|
||||
|
||||
分工:
|
||||
|
||||
```text
|
||||
label-master
|
||||
判断标签知识、边界、输出形态、target 合法性。
|
||||
|
||||
product-data
|
||||
做数据生成 review、draft、canonical records、导出。
|
||||
```
|
||||
|
||||
当用户给出模糊标签名时,应该先用 `label-master` 辅助确认:
|
||||
|
||||
```text
|
||||
标签是否存在
|
||||
使用 Agent 包装还是 function
|
||||
complex 默认是什么
|
||||
是否有高频混淆边界
|
||||
```
|
||||
|
||||
再进入 `product-data` 的生成计划。
|
||||
|
||||
## 7. 设计边界
|
||||
|
||||
`label-master` 负责:
|
||||
|
||||
- 标签知识检索。
|
||||
- 候选标签比较。
|
||||
- 边界解释。
|
||||
- 输出形态判断。
|
||||
- target 格式校验。
|
||||
|
||||
不负责:
|
||||
|
||||
- 生成数据集。
|
||||
- 线上日志挖掘。
|
||||
- 导出训练/评测格式。
|
||||
- 直接替用户确认争议边界。
|
||||
@@ -0,0 +1,186 @@
|
||||
# 09. 外部系统 Skill:ELK、SQL、模型迭代
|
||||
|
||||

|
||||
|
||||
## 1. 这类 Skill 的共同特征
|
||||
|
||||
外部系统 Skill 的核心不是复杂 prompt,而是把某个内部系统的调用方式、参数约定、依赖和输出格式打包起来。
|
||||
|
||||
典型形态:
|
||||
|
||||
```text
|
||||
SKILL.md
|
||||
写清楚什么时候用、参数怎么选、哪些动作需要确认。
|
||||
|
||||
scripts/
|
||||
执行真实外部系统调用。
|
||||
|
||||
python_exec
|
||||
作为统一执行入口。
|
||||
|
||||
python_package
|
||||
处理依赖缺失。
|
||||
|
||||
output/
|
||||
查询结果或报表写入当前 session output。
|
||||
```
|
||||
|
||||
## 2. elk-fetch
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/elk-fetch/SKILL.md
|
||||
skills/elk-fetch/elk_query.py
|
||||
```
|
||||
|
||||
定位:
|
||||
|
||||
```text
|
||||
按 request id 或查询条件读取小米内网 ELK 日志。
|
||||
```
|
||||
|
||||
实现方式:
|
||||
|
||||
- `SKILL.md` 写明支持的 profile 和查询方式。
|
||||
- 实际执行必须使用 `python_exec.script_path`。
|
||||
- 缺 `elasticsearch`、`urllib3` 时用 `python_package`。
|
||||
- 不让模型用 bash 手写临时 Python 查询脚本。
|
||||
|
||||
典型价值:
|
||||
|
||||
```text
|
||||
把“怎么查 ELK”这类个人经验变成团队共享能力。
|
||||
```
|
||||
|
||||
和 `online-mining-v2` 的区别:
|
||||
|
||||
```text
|
||||
elk-fetch
|
||||
更偏单次日志查询和调试。
|
||||
|
||||
online-mining-v2
|
||||
更偏批量挖掘、策略迭代、样本转换。
|
||||
```
|
||||
|
||||
## 3. data-factory-sql
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/data-factory-sql/SKILL.md
|
||||
skills/data-factory-sql/run_sql.py
|
||||
```
|
||||
|
||||
定位:
|
||||
|
||||
```text
|
||||
通过 Kyuubi HTTP API 执行数据工场 SQL,轮询状态并下载 CSV 结果。
|
||||
```
|
||||
|
||||
实现方式:
|
||||
|
||||
- 用户直接给 SQL 时,可以确认后执行。
|
||||
- 用户只给分析需求时,Agent 可以先生成 SQL 草稿,再让用户确认。
|
||||
- 执行必须通过 `python_exec.script_path`。
|
||||
- 输出默认写入当前 session output。
|
||||
|
||||
这个 Skill 的门禁重点是:
|
||||
|
||||
```text
|
||||
SQL 执行前确认。
|
||||
控制查询范围和 limit。
|
||||
输出路径清晰。
|
||||
失败时展示错误和可调整建议。
|
||||
```
|
||||
|
||||
## 4. model-iteration
|
||||
|
||||
位置:
|
||||
|
||||
```text
|
||||
skills/model-iteration/SKILL.md
|
||||
skills/model-iteration/scripts/
|
||||
```
|
||||
|
||||
定位:
|
||||
|
||||
```text
|
||||
模型训练、评估、数据准备和迭代流程辅助。
|
||||
```
|
||||
|
||||
这类 Skill 属于混合工程型:
|
||||
|
||||
- 有流程。
|
||||
- 有脚本。
|
||||
- 有配置。
|
||||
- 可能调用外部训练平台。
|
||||
- 高风险动作较多。
|
||||
|
||||
因此它更需要明确:
|
||||
|
||||
```text
|
||||
哪些步骤只是分析。
|
||||
哪些步骤会启动训练。
|
||||
哪些步骤需要用户确认。
|
||||
输出目录和实验记录在哪里。
|
||||
```
|
||||
|
||||
## 5. 外部 Skill 的通用约定
|
||||
|
||||
### 5.1 调用方式
|
||||
|
||||
优先:
|
||||
|
||||
```json
|
||||
{
|
||||
"script_path": "skills/<skill-name>/scripts/run.py",
|
||||
"stdin": "{...}",
|
||||
"timeout_seconds": 120
|
||||
}
|
||||
```
|
||||
|
||||
或者脚本在 Skill 根目录时:
|
||||
|
||||
```json
|
||||
{
|
||||
"script_path": "skills/elk-fetch/elk_query.py",
|
||||
"args": ["..."]
|
||||
}
|
||||
```
|
||||
|
||||
### 5.2 依赖处理
|
||||
|
||||
依赖缺失时:
|
||||
|
||||
```text
|
||||
python_package(action="install", packages=[...])
|
||||
```
|
||||
|
||||
不要:
|
||||
|
||||
```text
|
||||
bash pip install ...
|
||||
bash python ...
|
||||
```
|
||||
|
||||
### 5.3 输出处理
|
||||
|
||||
外部系统查询结果应该:
|
||||
|
||||
- stdout 给结构化摘要。
|
||||
- 大结果写入 `output/` 或 `scratchpad/`。
|
||||
- 返回实际文件路径。
|
||||
- 避免把大量数据直接塞进最终回复。
|
||||
|
||||
### 5.4 安全和确认
|
||||
|
||||
需要确认的动作:
|
||||
|
||||
- 执行大范围 SQL。
|
||||
- 启动训练。
|
||||
- 写外部路径。
|
||||
- 推送代码或数据仓库。
|
||||
- 导出可能包含敏感字段的线上数据。
|
||||
|
||||
只读、小范围、用户明确指定 rid 或 SQL 的查询,可以直接执行,但仍要控制结果规模。
|
||||
@@ -0,0 +1,59 @@
|
||||
# ZK Data Agent 技术架构说明
|
||||
|
||||
这组文档先服务于技术 review 和后续讲解材料沉淀,不做宣传表达,不做产品比较。
|
||||
每个章节尽量对应当前代码里的真实模块、函数和 Skill 实现,后续 `/doc` 页面可以从这里抽取内容做视觉化呈现。
|
||||
|
||||
## 阅读顺序
|
||||
|
||||
1. [基座 Runtime 架构](01-base-runtime.md)
|
||||
2. [Agent Loop 执行机制](02-agent-loop.md)
|
||||
3. [工具体系和 Tool Handler](03-tools.md)
|
||||
4. [Skill 体系和能力包约定](04-skills.md)
|
||||
5. [会话工作区、运行态和记忆](05-workspace-memory-observability.md)
|
||||
6. [product-data Skill 实现](06-product-data.md)
|
||||
7. [online-mining-v2 Skill 实现](07-online-mining-v2.md)
|
||||
8. [label-master Skill 实现](08-label-master.md)
|
||||
9. [外部系统 Skill:ELK、SQL、模型迭代](09-external-skills.md)
|
||||
|
||||
## 一句话定位
|
||||
|
||||
ZK Data Agent 的基座是一个 Web 化、多用户、可观测的 Agent runtime。
|
||||
业务能力通过 `skills/<skill-name>/SKILL.md`、`knowledge/` 和 `scripts/` 组织;稳定执行能力通过 Tool handler 或 Skill 内 portable scripts 承载;每次运行通过 Agent loop 让模型在“判断、调用工具、观察结果、继续判断”之间循环。
|
||||
|
||||
## 当前技术主线
|
||||
|
||||
```text
|
||||
Web UI
|
||||
-> backend/api/server.py
|
||||
-> LocalCodingAgent
|
||||
-> agent_prompting 组装系统提示词和 Skill 列表
|
||||
-> OpenAICompatClient 调模型
|
||||
-> 模型返回文本或 tool_calls
|
||||
-> agent_tools 执行 handler
|
||||
-> session workspace 保存 input/scratchpad/output/session.json
|
||||
-> run_state_store / event stream 推给前端活动区
|
||||
-> personal_memory 后台异步整理用户记忆和 Skill 记忆
|
||||
```
|
||||
|
||||
## 代码入口速查
|
||||
|
||||
| 主题 | 主要代码 |
|
||||
|------|----------|
|
||||
| Agent runtime | `src/agent_runtime.py` |
|
||||
| 系统提示词 | `src/agent_prompting.py` |
|
||||
| Tool registry / handler | `src/agent_tools.py`、`src/agent_tool_specs/` |
|
||||
| Skill loader | `src/bundled_skills.py` |
|
||||
| 模型兼容层 | `src/openai_compat.py` |
|
||||
| Web 后端 | `backend/api/server.py` |
|
||||
| 会话持久化 | `src/agent_session.py`、`src/session_store.py` |
|
||||
| 记忆后台 | `src/personal_memory.py` |
|
||||
| 数据生成 Skill | `skills/product-data/` |
|
||||
| 线上挖掘 Skill | `skills/online-mining-v2/` |
|
||||
| 标签知识 Skill | `skills/label-master/` |
|
||||
|
||||
## 后续维护原则
|
||||
|
||||
- 如果是在讲“基座怎么运行”,优先改 01-05。
|
||||
- 如果是在讲“某个 Skill 怎么做事”,优先改 06-09。
|
||||
- 如果代码实现发生变化,先更新对应章节,再考虑同步 README 或 `/doc` 页面。
|
||||
- 页面表达、图形素材、演示脚本不写在这里;这里只保留技术事实和设计边界。
|
||||
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 1.4 MiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 1.6 MiB |