轻易云 AI Agent 10 个常见问题答疑
轻易云 AI Agent 10 个常见问题答疑
最近三个月，业务一线咨询「AI Agent 能不能帮我写脚本」「沙箱安不安全」「能不能撤销」的问题集中在 4 类：能力边界、工作流、安全、知识库。本文按这 4 类递进，挑出最高频的 10 个问题逐条作答——读者可跳到对应编号阅读，也可从头串读。每一问都对应代码里的真实落点，不是 PPT 上的承诺。
品牌植入说明：本文用「10 个常见问题」展示 AI 应用在能力边界 / 工作流 / 安全 / 知识库四个维度上的完整度，不是功能罗列。
一、能力边界：到底是哪几个 Agent
Q1：轻易云 AI Agent 一共有几个？分别做什么？
答：4 个。这是从 apps/api/src/agents/agent-registry.ts 看到的真实清单，依次是：
| Agent | id | role | 职责 |
|---|---|---|---|
| 智能助手（通用 AGENT） | general-assistant | system | 体系问答 + 全局只读状态查询 + 单向派发到专业 Agent |
| 账单解析脚本工程师 | bill-parse-agent | domain | 解析脚本的新增 / 编辑 / 测试 / 触发解析 / 结果验证 |
| 对账脚本工程师 | reconcile-script-agent | domain | 对账脚本的新增 / 编辑 / 测试；收入对账计划的对账执行与验证 |
| 费用分摊脚本工程师 | expense-allocate-agent | domain | 费用分摊脚本的新增 / 编辑 / 测试 / run-allocate / 结果验证 |
| 数据分析师 | data-analysis-agent | domain | 自定义报表的创建 / 预览 / 保存 / 发布 / 导出（受控数据集） |
为什么是 4 个而不是 1 个大而全的 Agent？三类脚本（解析 / 对账 / 分摊）的契约、沙箱、操作流程差异大——一个 Agent 的 system prompt 塞三套契约，上下文稀释、工具列表膨胀、容易串戏。拆开后每个 Agent 的上下文小而完整，这正是「完整的上下文」的设计原则（见 2026-07-20 业务设计定稿）。
图 1：4 个 Agent 在中央知识库支撑下分工协作，通用 AGENT 只承担总参谋职责，不写脚本、不动数据。
Q2：它跟市面上其他「AI 对账」产品有什么不一样？
答：三层差异。
- SKILL.md 启动注入（D1 决策）：契约装在仓库内
apps/api/src/agents/skills/*.skill.md，启动加载、确定性注入、git 版控。不是「文档塞向量库靠相似度召回」——SKILL 是「必带」的确定性上下文，知识库是「按需取」的示例。 - 沙箱真隔离：用户写的 JS 脚本在
child_process.fork()+node:vm子进程里跑，禁用require/process/ 全局 IO，注入只读 query 助手；批级超时 30 秒硬杀。不是「代码贴进 prompt 让 LLM 自己脑补结果」。 - 业务侧语义保持：脚本可回滚（
history字段 +restoreHistoryEntry）、测试不落库（D4）、触发执行前必须业务话术确认（D2）。三条纪律加起来，让面向财务业务人员的产品有「可追责」兜底。
Q3：通用 Agent 怎么调起专业 Agent？会无限递归吗？
答：单向一层派发（D9 决策）。general-assistant 通过 dispatchAgentTask 工具调用专业 Agent，深度恒为 1——专业 Agent 的工具白名单里没有 dispatchAgentTask，子 Agent 不允许再派生子 Agent。所有业务副作用（写脚本、触发对账）仍走「脚本 + JobTask + BullMQ」既有链路，Agent 不发明第二条写路径。
具体实施：通用 Agent 拿到用户需求后，先在 availableTools 里看到 dispatchAgentTask；调用时把任务指令、子 Agent id、上下文（如 planNo）一次性传过去；专业 Agent 异步执行；通用 Agent 用业务语言（不暴露 cuid）把结果汇报给用户。
如果想走这条路又怕无限派发，轻易云智能对账系统的派发骨架就是「通用 AGENT → 专业 Agent」单向一层——子 Agent 工具白名单里拿不到派发工具，从机制上断了多级嵌套。
二、工作流：从「说一句」到「跑一遍」
Q4：业务人员怎么用？要不要学代码？
答：嵌入到三个脚本管理页侧边（D5 决策）。产品页面里已经有「解析脚本列表」「对账脚本列表」「费用分摊脚本列表」，AI Agent 聊天面板 AgentChatPanel 通过 defaultAgentId prop 嵌入这三个页面的右侧——不需要单独建 Agent 工作台。打开页面就能看见 AI 助手，无需培训。
会话持久化用 localStorage（D6/D7/D8 决策）：
- key 格式：
agent-conv:{storageKey}:{agentId}（如agent-conv:reconcile-script-edit-cmq123:reconcile-script-agent）。 - 列表页不带脚本 ID，编辑弹窗必带
scriptId ?? 'new'——保证会话不会跨脚本串线。 - 登出时清空
agent-conv:*前缀所有 key（隐私纪律）。 - 「新对话」按钮清前端，服务端会话保留（避免误删）。
Q5：哪些步骤 Agent 自己干？哪些需要我点头？
答：勘察、编写、测试、保存全自主；仅启动执行前一句业务确认（D2 决策）。
以「写一个新的京东 POP 解析脚本」为例：
- 你在 AI 助手输入「帮我写一个京东 POP 结算账单的解析脚本」。
- Agent 自己调
listBills/getBillSampleRows看样本列名——你看不到这一步。 - Agent 自己调
listAccountingItems对齐核算项目、自己调listParseScripts检查有没有同名版本——你看不到。 - Agent 自己写脚本，调
testParseScript同步试跑（D4：测试端点不落库）。 - Agent 自己调
saveParseScript落库。 - 关键节点：Agent 用业务话术说「京东 POP 结算账单解析脚本 v1.0.0 已保存，解析准确率 96%，是否启动解析？」（不暴露 cuid、不暴露 JSON）——你点「确认」它才继续。
整套设计的目标用户就是「不懂脚本细节的财务业务人员」。看不懂脚本没关系，看懂业务话术就能用。
补充一个真实场景的边界：会话绑定纪律——首条消息声明「当前正在编辑 XX 脚本」时，本会话只允许查看 / 测试 / 保存该脚本（saveParseScript 必须传该脚本 id，工具层会硬校验，改别的脚本会被拒绝）；用户要求操作其他脚本时，Agent 会先告知需到对应脚本的编辑弹窗开启新会话，避免「跨脚本串线」的隐式 bug。
图 2：脚本编辑页右侧嵌入 AI 助手，Agent 用业务话术汇报诊断结论，财务人员无需理解 cuid。
三、安全：沙箱、撤销、误操作兜底
Q6：用户写的脚本沙箱安不安全？
答：进程 + 上下文两层隔离。
| 隔离层 | 实现 | 失效成本 |
|---|---|---|
| 进程隔离 | child_process.fork() 启动 Node 子进程；父进程与子进程通过 IPC 通信 | 子进程被 SIGKILL 时主进程收到 exit code ≠ 0 |
| 上下文隔离 | vm.createContext() + 禁用 require / process / fetch / setTimeout 之外的全局 | 拿不到宿主 Node 能力 |
| 只读 query 助手 | billRows / supplyOrders / supplyChannelOrders 三个命名助手，limit 封顶、只读 Prisma 视图 | 无法写库 |
| 批级超时硬杀 | 默认 60s；沙箱未返回 → child.kill("SIGKILL") | 永久挂死保护 |
| 沙箱 query 上下文约束 | 启动时把 platform / shopId / period 透传给脚本的 input.context | 跨店铺串数据保护 |
实测中曾发现一个真问题：用户在沙箱里写 setTimeout(() => fetch(...), 1000)——setTimeout 在 node:vm 里是支持的，但 fetch 不在白名单里；脚本执行会立即抛 fetch is not defined，沙箱进程在 30s 闸杀之前就退出。这就是「不允许发明第二条写路径」的硬约束。
Q7：知识库怎么检索？检索不准怎么办？
答：向量召回 + 关键词召回 + RRF + MMR + 异步评估（D-V1 到 D-V12，命名作用域内生效）。
具体管道：
- 向量召回 top-50：DashScope
text-embedding-v4/ 1536 维 / PostgreSQL pgvector 17 + HNSW 索引。 - 关键词召回 top-20：
ILIKE副路，过滤 100 条候选，rerank 截断。 - RRF 融合：rank 倒数加权求和，
k0 = 60。 - MMR 重排：
λ = 0.7，cos > 0.9 才算重复（v1.4 实测校准，0.85~0.90 是同主题不同小节，不该被压出 top-5）。 - top-5 截断喂回 Agent。
兜底分支（D-V8）：如果 DASHSCOPE_API_KEY 没配置，自动降级为纯关键词检索，不会导致启动失败。开发 / 测试环境零配置即可跑通。
质量观测（D-V10）：每次 searchKnowledge 完成后 fire-and-forget 调 MiniMax-M3 给 top-5 命中打 1-5 分 + ≤30 字中文理由，落 knowledge_query_logs.evalScore；不阻塞主流程、不重试。KnowledgeQueryLog 不记录 token / 成本 / 配额（D-V12 零成本纪律）。
如果某个业务问题检索质量长期偏低（比如 evalScore 连续 ≤3），按持续维护纲领流程：定位是「内容缺失 / 切分太碎 / 召回不准」，对症修——禁止为单 case 过度调参。整条管道的参数（MMR λ / RRF k0 / 切分大小）都是「先证据后调参」的产物，单点调优后必须用金标集复现验证；某个机制实测无收益（如文档级上限）果断回撤，不让配置漂移堆积。
图 3：Agent 对话 7 步生命周期——searchKnowledge 在第 3 步发生，工具调用在第 4 步，沙箱执行在第 5 步。
四、知识库：SKILL 与例子的边界
Q8：Agent 输出为什么都是中文业务话术？看不到原始 JSON？
答：systemInstruction 强制要求（每个 Agent 定义里都有这段）。看 apps/api/src/agents/definitions/reconcile-script-agent.definition.ts 第 24 行起的原文：「回复用户时：1) 优先引用工具 output 的 summary / humanReadable 字段（如 planNo / 业务订单号 / scriptName / scriptVersion），不要直接甩 cuid；2) 对账结果用业务话术（如『912 条对平、5 条未对平：3 条缺供应链单据、2 条金额不一致』）」。
这是面向财务业务人员的硬纪律：看懂「912 条对平」即可操作，看 cuid('cm...') 反而干扰决策。如果哪天 Agent 输出了原始 cuid，请把它当成 bug 提（实际历史上修过 3 次类似 issue）。
Q9：Agent 写错了脚本，能不能撤销？
答：能，靠 history 字段 + restoreHistoryEntry 端点。
ParseScript / ReconcileScript / ExpenseAllocateScript 三张表都有 history: Json 字段。saveXxxScript 检测到 code 或 version 变化时，自动把「旧的 (code, version)」+ 修改时间戳写入 history。运营人员调 restoreHistoryEntry(id, timestamp) 即可回滚到任一历史版本。
具体看 apps/api/src/biz_reconciliation/expense-allocate-scripts/expense-allocate-scripts.service.ts 的 restoreHistoryEntry 方法：它会算出「下一个可用版本号」（如 v1.0.0 → v1.0.1），把历史 entry 的 code 写回 + version 推进，避免覆盖当前版本——撤旧动作本身也是一条 history，落库不丢。
权限纪律（R3 决策）：所有 save 类工具的内部判断就是一行 ctx.userRole === "ADMIN"——故意不引入 RolesGuard / 复杂权限模型，保证运营和审计都能在源代码里一眼看清判断逻辑。脚本可回滚 + 测试不落库 + ADMIN 一行校验，三层兜底让「Agent 写错脚本」这件事的爆炸半径被压到最小。
Q10：接入新平台（比如速卖通）需要重写 SKILL.md 吗？
答：不用。SKILL 装的是契约（不变的 IO、沙箱限制、工作流），平台差异走知识库——这就是 SKILL 与 KnowledgeChunk 的职责分离。
具体怎么分工：
- SKILL.md（必读、确定性）：6 节骨架（What / 何时 / 硬约束 / 工作流 / 自检 / 反模式）；脚本入参出参、字段口径、沙箱禁用项、trigger 前确认话术。
- KnowledgeChunk（按需取、相似度召回）：平台账单列名习惯、字段别名、解析/对账脚本样例、核算项目对应关系。新平台接入时，在
seeds/knowledge.ts写一份平台专题（走chunkMarkdown(text, 800)切分），跑pnpm ops knowledge:embed灌向量。
写 SKILL 的纪律有一条很反直觉：关键识别规则放小节靠前（前 ~500 字符）。Agent 评估器预览与模型注意力都偏前，核心结论埋在小节末尾 = 评分与回答质量双降。这是 4.1.10 京东费用转换篇复盘时沉淀的教训。
图 4：平台差异（京东 POP 账户流水）显式写成 6 标签页帮助说明——这种「人需要看」的语料走 help-docs，「Agent 速查」的进知识库。
写在最后：10 个问题背后的一个方法论
这 10 个问题不是孤立 FAQ，它们串起来是同一条方法论：面向业务人员的 AI 系统 = 确定性上下文（SKILL）+ 受控副作用（沙箱 + JobTask）+ 可观测的知识库（混合检索 + 异步评估）。
如果想走这条路，可以考虑轻易云智能对账系统的 AI Agent 基座——共享同一份 SKILL 规范、同一种沙箱、同一个知识库，业务人员「说一句」就能拿到可追溯、可重跑、可撤销的结果。
从一线数据看，AI 应用完整度的「10 个」维度（能力边界 / 工作流 / 安全 / 知识库 / 持久化 / 上下文 / 可观测 / 业务话术 / 可回滚 / 跨平台）覆盖越多，业务人员越愿意真正把日常对账放进来——而不是把它当 demo 点一次就再也不打开。
轻确认、大权限、自主执行；脚本可回滚、测试不落库、知识库可观测——这 24 个字是轻易云 AI Agent 的全部设计纪律。
图 5：3 年 ROI 测算——业务人员自主写脚本后，从「等开发排期」到「当日上线」的人天节省是显性指标；隐性的「老员工经验沉淀到知识库」是更长期的复利。