Agent 与 Skill 工程化实践

从 Chatbot 到 Agent

判断一个系统是不是 Agent，可以问一句：下一步由谁决定？

形态	决策者	流程	适用场景
Chatbot	无	一问一答	翻译、简单问答
Workflow	开发者	代码预定义	路径稳定、强可审计
Agent	模型	运行时动态选择	意图开放、多工具组合

该平台同时保留固定 DAG 和 Agent：稳定的处理路径交给 DAG，开放性的内容分析交给 Agent。这样既保留可预测性，又能让模型在工具结果不完整时决定是否换工具或补充分析。

Agent 的工程化边界

一个可维护的 Agent 至少要拆出四层：

1. 输入契约：用 Pydantic 描述情报文本、发布者、市场状态和 DAG 证据。
2. Prompt 层：从 Prompt 管理器读取版本化系统提示词，运行时再注入必要的策略约束。
3. 执行层：负责模型调用、工具循环、超时、重试和 fallback model。
4. 输出层：把模型响应转换成严格的结构化结果，并拒绝无法解析的内容。

Agent 运行器的职责就是把这些边界组合起来：校验启用工具、构造模型和 fallback、注册工具钩子、设置结构化输出，最后将模型响应转换成结果对象。它不直接承担数据库写入或展示逻辑，便于本地测试和线上节点复用。

Skill 是什么

Skill 不是“把一段 Prompt 换个名字”，而是围绕一种稳定能力打包的工作说明：触发条件、输入输出、工具选择、限制条件、验证方法和安全边界。我的 Skill 选型遵循三个原则：

• 先看边界：只有当任务需要一组可复用的流程知识时才引入 Skill。
• 优先组合：例如先用 brainstorming 澄清需求，再用 systematic-debugging 定位问题，最后用 verification-before-completion 验证结果。
• 可验证：Skill 必须给出可观察的产出，而不是只要求“尽量做好”。

在工作中，我学习了 Codex 的 Skill/Agent 机制，把浏览器验证、文档整理、调试和代码检查变成可重复的工作流。这样做的价值是减少每次重新解释背景的成本，也让协作者更容易复用成熟方法。

工具白名单与安全

Agent 的工具不能全部暴露给模型。项目通过配置维护启用工具列表，运行前计算实际工具名与白名单的差集，发现未启用工具立即拒绝运行。工具还需要：

• 限制输入参数和调用次数。
• 为网络、数据库等外部副作用设置超时。
• 在结果中说明成功、失败或权限不足的原因。
• 不把 Cookie、Token、私有 URL 等凭证放进 Prompt、日志或案例文件。

评分 Agent 与情报 Agent 协同

项目中的调度器先调用评分 Agent 生成评分，再根据输入类型、来源等级和分数门槛判断是否触发完整分析 Agent。触发前还会检查候选是否为空、流程是否完成、重投递是否稳定以及本次运行是否已执行过。这个设计说明 Agent 不应该“看到输入就直接运行”，而应由明确的条件和状态机控制成本与副作用。

小结

Agent 的核心能力是动态决策，Skill 的核心能力是复用方法。真正的工程化工作，是把模型的自由度限制在清晰的输入、工具、输出和验证边界内，让 Agent 既能处理开放问题，又能被测试、监控和回滚。