标书排雷：售前经理的“减负”计划

在售前工作中，标书分析往往是耗时最长且最容易遗漏细节的环节。动辄几百页的招标文件，包含着大量的技术指标、合规要求与潜在的“排雷”点。

为了提升售前效率，我计划构建一套基于 Dify 的售前经理 AI Skill 工具库。本文将分享该项目的设计理念与技术实现。

1. 为什么选择 Agent 工具库？

标书分析的痛点在于“非结构化数据”与“动态标准”。不同行业、不同项目、不同客户的排雷规则完全不同，普通的搜索引擎或通用 LLM 无法处理复杂的规则约束。

我们需要的是一套可定制的 Agent 体系：

• 竞品分析：自动提取招标文件中的关键需求，对比已有产品优势。
• 标书排雷：基于规则库，动态识别招标文件中的敏感排他条款。
• 配置报价：根据需求自动匹配推荐方案。

2. 技术架构设计

整个系统的核心在于**“数据前置处理 + Dify 智能编排”**。

第一阶段：标书脱水 (Data Dehydration)

全量投喂 PDF 给 LLM 是极低效的。我设计了一个基于 Python 的前置处理流程：

• 提取与降维：使用 pymupdf 提取文本，移除页眉页脚及冗余法律模板。
• 结构化归一：将分散的表格和条款转化为语义清晰的 Markdown 结构。
• Token 节约：只保留关键技术要求与限制条款，剔除 50% 以上无关字符，显著降低 LLM 压力，提升 RAG 检索准确度。

第二阶段：基于 Dify 的动态排雷

Dify 提供了理想的 Workflow 与知识库分组能力：

• 动态标准配置：行业标准与规则以参数形式输入。
• 动态 Prompt：Agent 根据当前“行业 + 场景 + 客户风格”标签，动态加载对应的排雷标准库。

3. 未来的扩展：社交生态发布

商业计划的最后一步是公域传播。利用 Dify 的 API，我们将排雷后的合规知识点，自动摘要并脱敏，分发至小红书或抖音，构建售前经理的专业个人 IP。

当一个个人 Agent 同时负责聊天、记忆、博客、Lark 卡片、多云 VPS、SSH、systemd、Docker、审批和审计时，最先出现的问题不是模型不够聪明，而是边界越来越难解释。

继续给 Agent 增加工具，最终会得到另一个通用 Agent；改用成熟 Agent，又可能丢掉已经验证过的运维安全能力。

更好的拆法是：

保留 Lark 多云运维的专业能力，但把它从通用 Agent 中抽出来，做成独立的 luck-ops-mcp。

Hermes、OpenClaw、Codex 或其他 MCP Client 负责理解用户意图；luck-ops-mcp 只负责资产、权限、审批、执行和审计。

产品边界

luck-ops-mcp 负责：

• AWS、GCP、Azure 等目标目录；
• 主机、资源、服务和日志查询；
• 固定、登记过的运维操作；
• 用户、目标、服务和操作权限；
• Lark 人工审批；
• 执行前置条件、结果验证和回滚说明；
• 操作状态和审计记录。

它不负责：

• 通用聊天；
• Agent 推理和任务规划；
• 博客写作、英语学习和知识问答；
• Agent 长期对话记忆；
• 任意远程 Shell；
• 根据模型临时生成系统命令。

这样可以把系统分成三层：

交互层：Lark / Web / CLI
推理层：Hermes / OpenClaw / 其他成熟 Agent
执行层：luck-ops-mcp / vps_sysops

其中只有执行层持有运维凭据，推理层永远不是最终授权者。

为什么适合 MCP

MCP 把上下文和动作分成 Resources 与 Tools：稳定、可读的资产适合 Resources，会产生行为的操作适合 Tools。客户端可以通过标准协议发现 schema，而不需要为每个 Agent 重写插件。

我曾经把个人助理的每一层都自己实现：Lark WebSocket、卡片、Agent Loop、Goal Runtime、记忆、定时任务、多模型 fallback、工具审批和多云 VPS 运维。

这样做最大的收益是理解了边界，最大的代价也是边界——一旦通用 Agent 能力持续扩张，维护一个个人助手就会逐渐变成维护一个框架。

更合理的方向是：

成熟 Agent 负责通用助理能力
标准 MCP 负责专业工具
服务端策略负责最终安全边界

但“成熟”和“轻量”不能只看项目介绍。这篇文章使用同一组需求评估 2026 年几类主流选择。

我的真实需求

这不是通用 Agent 排行榜。目标环境是一台低资源 VPS，主要服务一个人：

• 通过 Lark 私聊和群聊使用；
• 处理问答、翻译、摘要、Idea、纪要和博客；
• 保存少量长期偏好与会话历史；
• 支持定时提醒和主动推送；
• 通过 MCP 接入 GitHub、知识库和多云运维；
• 模型不可用时，核心运维控制面仍然可查询；
• 重启、备份、恢复和发布等动作必须人工批准；
• 使用远程模型，不在小 VPS 上运行本地大模型。

基于这些约束，我把候选分成两类：

成品助理：Hermes Agent / OpenClaw / nanobot
开发框架：OpenAI Agents SDK / PydanticAI / Agno / LangGraph

成品助理的优势是少造渠道、记忆和调度；框架的优势是运行时可控，但应用外壳仍要自己写。

先定义“成熟”

一个仓库更新频繁、Star 很多，不等于适合长期运行。我更关心：

1. 配置和升级有没有稳定入口；
2. 会话和任务能否在重启后恢复；
3. 渠道是否处理去重、重连和用户隔离；
4. MCP 是否支持过滤、超时和失败降级；
5. 高风险工具是否有确定性权限边界；
6. 日志、健康检查、备份和回滚是否可操作；
7. 安全修复是否持续发布；
8. 能否关闭不需要的工具，而不是默认把整台主机交给模型。

个人助理生态仍然变化很快。这里的“成熟”是相对成熟，不等于 systemd、SQLite 或 Ansible 那样经过多年稳定周期。

很多项目把“轻量”写在 README 里，但这个词经常只代表安装命令短、核心代码少，或者演示时能在一台小机器上启动。

对一个需要 24 小时在线的个人助理来说，这些都不够。真正的问题是：它空闲时占多少资源？连续调用工具后会不会涨内存？断网、重启、模型限额和审批暂停之后还能不能回来？

因此我给“极简 Agent”定义了一套实用测试基准。它不评模型知识，也不追求实验室里的漂亮分数，只回答一个工程问题：

这个 Agent 能不能在低资源 VPS 上，长期、稳定、安全地替一个人处理真实任务？

极简不是一个内存数字

一个个人 Agent 至少包含四层：

消息入口 → Agent Runtime → 外部模型 → 工具与状态

只统计 Agent 主进程的 RSS，会漏掉浏览器、Node bridge、MCP 子进程、后台 worker 和模型代理。只统计空闲内存，也会漏掉长上下文、文件解析和工具输出带来的峰值。

所以“轻量”应该同时满足：

• 常驻资源低；
• 任务峰值有上限；
• 空闲后能够回落；
• 不产生孤儿进程；
• 重启后能恢复必要状态；
• 失败不会演变成无限重试；
• 高风险动作不会绕过审批。

测试环境必须先固定

不同机器、Python/Node 版本和模型端点会显著影响结果。每次测试至少记录：

host:
  cpu: 2 vCPU
  memory: 1 GiB
  swap: 1 GiB
  os: Ubuntu 24.04
runtime:
  version: git commit / release tag
  language: Python 3.12 / Node 26 / Go 1.x
model:
  endpoint: remote OpenAI-compatible
  model: fixed model id
  context_window: fixed
features:
  channel: Lark WebSocket
  memory: SQLite or files
  mcp_servers: [luck-ops]
  browser: disabled

不要一边测 Agent A 的最小配置，一边给 Agent B 打开浏览器、语音和十个插件。功能集合必须一致，模型也必须一致。

这是 DSH 系列的最后一篇。我们之前问过：minimal preset 只有两个工具，它是否已经是最小化 Agent？答案是：对模型可见能力来说接近最小，对真实运行时来说并不是。

DSH 的四种 preset 不是四个产品

DSH 当前把 Agent 能力组合成几类 preset：

standard   完整 Coding Agent
ptc        TypeScript Code Mode / PTC
minimal    persistent bash + str_replace_editor
creator    运行时检查和插件实验

它们不是四个独立程序，而是同一个 Cordis Runtime 上的不同能力组合。

这一区分很重要：preset 决定的是某个 Agent Scope 可以看到和使用哪些能力，而不是重新启动一套完全不同的 Agent 实现。

minimal 为什么看起来很小

DSH 的 minimal 配置对模型暴露的主要能力只有：

1. persistent bash
2. str_replace_editor

同时它关闭或抑制了很多额外上下文：

• 不加载完整 Coding Agent 的复杂工具集；
• 不注入运行时上下文；
• 不使用默认的复杂压缩能力；
• 使用固定、短的系统提示；
• 让 Bash 在多个 step 之间保持状态。

相关实现可以直接看 minimal agent preset 和 minimal runtime 设计记录。

这是 DSH 系列的第三篇。很多 Agent 都声称支持“记忆”，但这个词往往同时指会话保存、上下文压缩、跨会话召回和目标续跑。DSH 的有趣之处，是把这些问题明确拆开了。

先把“记忆”拆成五件事

Session Persistence   保存发生过什么
Context History       决定模型当前看到什么
Compaction            压缩当前可见历史
Long-term Memory      跨会话主动召回知识
Goal State            Agent 还要继续完成什么

DSH 内置支持前四项中的一部分：它强内置会话事件日志和上下文压缩，Goal 是持久任务状态；真正的语义长期记忆则通过外部 Provider 或 MCP 接入。

1. Session Persistence：日志才是事实来源

DSH 不把 messages[] 当作唯一状态，而是将一次交互保存为 append-only 的类型化事件：

turn/start
user/message
assistant/chunk
assistant/message
tool/call
tool/result
step/end
turn/end

模型的历史消息由这些事件重新派生。这样可以让 UI、Replay、Fork、Telemetry 和恢复逻辑共享同一份事实来源。Session 文档

持久化层通过 ctx.sessionPersistence 抽象出来，目前支持 JSONL 和 SQLite 后端。写入采用批处理和 flush checkpoint；崩溃恢复时，DSH 会识别没有关闭的 turn，并以 interrupted 结束它，而不是粗暴截断日志。Persistence 文档

这是一种“事实优先”的设计：

原始日志尽量完整
模型上下文可以变化
历史投影可以重新计算

2. Compaction：压缩可见表面，不删除原始历史

上下文接近模型窗口时，DSH 不直接删除旧事件，而是选择一段旧的 surface，调用 summarizer 生成摘要，然后追加一个 checkpoint：

上一篇讨论了 DSH 为什么不应该被简单看成“另一个 Codex”。这一篇进入源码架构：DSH 的真正内核不是一个大而全的 Agent 类，而是一套用来组装 Agent 的插件运行时。

先给一个简化模型

Runtime = Profile + Bundle + Patch + Plugin
Agent   = Scoped Context + Session + Agent Driver
Turn    = LLM Request + Tool Pipeline + Durable Events

DSH 官方文档对自己的描述很直接：模型适配器、工具注册表、会话日志和 Agent Loop 都是插件；没有一个需要被所有扩展修改的 privileged core。DSH Architecture

这里的“没有核心”不是说系统没有基础代码，而是说：基础服务存在，但业务能力没有被绑死在一个不可替换的中心对象里。

Cordis：Context 是服务仓库

Cordis 是 DSH 底层的插件框架。每个插件可以向共享 Context 注册服务：

ctx.llm          模型适配器
ctx.sessions     会话存储
ctx.tools        工具注册表
ctx.systemPrompt Prompt 组装
ctx.fs           文件系统能力
ctx.sandbox      沙箱能力
ctx.agents       Agent 注册表

插件不直接依赖具体实现，而是通过 ctx.<key> 找到能力；依赖通过 inject 声明，加载顺序由服务依赖关系决定。插件注册的工具、Prompt、Provider 和事件监听器都会通过 effect 安装，并在插件卸载时撤销。Cordis Primer

这是一组关于 DeepSeek Harness（简称 DSH）的源码级解读。第一篇先回答一个很现实的问题：市场上已经有 Codex、Claude Code，为什么还需要 DSH？

先说结论

如果需求是“给我一个现在就能写代码的 Agent”，普通用户没有太多理由选择 DSH。Codex 和 Claude Code 的优势在于完整的产品体验：安装、权限、上下文、编辑、测试、恢复和日常交互都已经被包装好了。

DSH 的合理定位不是“另一个更好用的 Codex”，而是：

一个可编程、可替换、可嵌入、可自托管的 Agent Runtime，同时提供一个 DeepSeek 原生的 Coding Agent。

这两个定位看起来相近，实际上面对的是不同买家。

三种产品不是同一层

可以把 Agent 市场拆成三层：

模型层：DeepSeek / OpenAI / Anthropic / 自建模型
运行时层：DSH / OpenAI Agents SDK / Google ADK / LangGraph / Pi
产品层：Codex / Claude Code / 企业内部 Agent 产品

Codex 和 Claude Code 的核心目标是让用户完成任务。它们当然也在开放 Skills、MCP、SDK 和企业部署能力，但用户不需要先理解运行时内部结构，就可以开始工作。Codex 开发者主页、Claude Code CLI 文档

DSH 的重点则是把运行时本身暴露出来：模型适配器、工具注册表、Session Log、Agent Loop、沙箱和审批都可以通过插件和配置组合。官方架构文档甚至明确写道，产品中的这些部分都属于插件，而不是一个必须修改的特权核心。DSH 架构文档

一、为什么选择 Playwright？

Playwright 是微软于 2020 年开源的新一代浏览器自动化工具，如今已成为 E2E 测试和浏览器自动化领域的主流选择。与 Selenium 等传统工具相比，它有三个核心优势：

• 统一 API 跨浏览器：Chromium、Firefox、WebKit 三套引擎通过一致的 Python API 操作，无需切换语法。
• 原生异步 + 自动等待：底层基于 WebSocket 维持浏览器连接，元素操作自带重试和等待，避免了 Selenium 常见的 time.sleep 毒瘤。
• 开箱即用的工具链：代码录制器（CodeGen）、Trace Viewer、截图对比、拦截 Mock 等能力均内置，不必再拼装第三方库。

如果你的需求是稳定地模拟用户操作、跑端到端测试，或者抓取强 JS 渲染页面，Playwright 的学习成本远低于 Selenium 全家桶。

二、环境搭建

2.1 前置条件

• Python：官方推荐 Python 3.9 及以上版本（3.7-3.8 也能运行，但部分特性受限）。
• 操作系统：macOS、Windows、Linux（包括 Docker 容器）均支持。

2.2 安装步骤

# 1. 创建并激活虚拟环境（推荐）
python3 -m venv .venv
source .venv/bin/activate   # macOS / Linux
# .venv\Scripts\activate  # Windows PowerShell

# 2. 安装 Playwright 库
pip install playwright

# 3. 下载浏览器驱动（Chromium、Firefox、WebKit）
playwright install

# 4. 安装 pytest 插件（测试场景必备）
pip install pytest-playwright

💡 国内加速：如果下载浏览器慢，可使用清华镜像：

过去两年，几乎每个技术团队都做过一个能"跑通"的智能体 demo——接几个工具，套一层 ReAct 循环，输入一句自然语言，输出一堆看起来很智能的行为。这类 demo 做起来不难，难的是下一步：把它交给真实用户，接入真实系统，让它在没有人盯着的情况下，连续跑几个月不出岔子。

这中间隔着的，不是"模型能力"的鸿沟，而是可预测性的鸿沟。一个 demo 智能体可以偶尔走神、偶尔重试、偶尔给出一个"看起来合理但其实跑偏"的答案，反正是演示，出了问题重跑一次就好。但生产系统不允许这种随机性——尤其是当智能体接触的是资金、客户数据、生产环境配置这类不可逆操作的时候。

2026 年的企业级智能体实践，基本已经收敛出一套相对一致的答案：不是让智能体更自主，而是让它更可控。这篇文章梳理一下，支撑这种"可控自主"的核心能力到底是哪几层。

校对注：本文初稿由一篇行业综述整理而来，关键监管与技术断言（EU AI Act Article 14、NIST AI 600-1 GenAI Profile）已逐一核实；部分采用率/市场份额数据来自第三方调研，文中已标注为"业界观点"而非定论。与笔者此前的《LangGraph 是负担还是利器？》一文视角互补——那篇从"单角色个人助手不该上 LG"出发，本篇从"生产级必须可控"出发，结论殊途同归：自主度的边界应由业务风险等级决定，而非模型能力。

一、为什么"更自主"不是正确方向

早期很多团队的直觉是：模型越强，就应该给它更大的自由度，让它自己规划、自己决定工具调用顺序、自己判断什么时候该停。这个思路在 demo 阶段很吸引人，但放到生产环境会迅速暴露问题——你没法审计一个"完全自由发挥"的决策链，也没法向合规部门解释"智能体为什么会这么做"。

企业级智能体架构的核心特征，正在从"最大化自主性"转向"有边界的自主性"。行业分析普遍认为，真正规模化落地的组织会共享同一套架构模式：在自主推理能确实创造价值的地方使用智能体，在需要一致性的地方使用确定性规则，在利害关系要求问责时引入人工判断——三者结合，而不是单纯堆叠模型能力。

二、六层核心能力

把各家企业级实践拆开看，基本都在做同一件事的六个侧面。

1. 确定性路由层：把开放世界压缩成有限状态

这是最基础也最容易被忽视的一层。核心思路很简单：不让大模型自由生成"下一步该做什么"，而是先定义一个有限的动作空间（比如"调用工具"“请求澄清"“判断无法处理"“任务完成”），模型只能在这个空间里做选择，选择的结构由类型系统（比如 Pydantic）强制约束。

action_type: tool_call | clarify | cannot_proceed | done

这一步看起来朴素，但效果是把"自由文本生成"的不确定性，变成了"有限选项分类"的确定性——后者好测试、好回归、好追责得多。

2. Human-in-the-Loop 中断门：不可逆动作前的强制刹车

在编排图里预设中断点，任何被标记为高风险或不可逆的操作，执行前必须经过人工确认。这不是"智能体表现不好才需要人工介入”，而是架构层面的默认设计——资金操作、外发通信、生产配置变更这类动作，不管模型多自信，都要走审批。

这一层的关键设计难点不在"要不要加审批”，而在"审批粒度怎么定"。粒度太粗，所有操作都要人工确认，智能体失去意义；粒度太细，风险操作可能漏网。比较成熟的做法是按风险分级（risk-tier）给每个工具打标，只有中高风险的操作才触发中断。

3. 审计平面：让每一步决策都能被倒查

记录每一次工具调用、每一次路由决策、每一个最终输出的来源，使得出问题之后能够对智能体的推理路径做取证式的完整重建。这一层的价值不在正常运行时体现，而在出事故的那一刻——没有完整审计链，你连"智能体在哪一步犯了错"都说不清楚，更别说改进。

技术实现上，主流做法通常包括：结构化的调用日志（区分请求模型和实际使用模型，便于发现静默降级）、决策快照（人工批准时看到的是什么状态）、以及近年逐渐标准化的 OpenTelemetry GenAI 语义约定，用来统一不同框架间的追踪数据格式。

4. 评估回路：从"跑起来了"到"跑得对"

生产级智能体需要专门针对智能体逻辑设计的自动化回归测试，依据基线评分标准衡量推理路径质量，而不只是"程序没报错"。更进一步的做法是把评估探针嵌入实际推理流程，在线上实时运行而非只在部署前测试，给出带理由的可机读判定结果——这类做法已经开始被 NIST 等机构的指导文件所参考（如 NIST AI 600-1《Generative AI Profile》已将 LLM-as-judge 等评估思路纳入风险管理的参考框架）。

一个容易被低估的点是：评估不应该只测"最终答案对不对"，还要测"中间决策合不合理"——比如任务分解是否遗漏了关键维度，工具选择是否有更优解但没被采纳。这类语义层面的评估，通常需要引入另一个模型做裁判（LLM-as-judge），而不能只靠规则断言。

5. 模型网关：一层薄薄的保险丝

一个集中化的代理层，统一管理模型路由和策略，负责限流、追踪 token 预算，并提供跨供应商的故障转移。对企业而言，这一层的价值不只是省钱和防崩，还包括权限控制——哪个智能体、哪个任务能调用哪个模型，是需要被显式管理的资产，而不是散落在各处的 API Key。