01
Agent 工作流设计
将任务拆成意图、检索、生成、校验、执行和结果回填。证据：Text2SQL 与 Agent Gateway。
AI Agent / LLM Application / NLP
AI Agent 产品与工程实践｜数据科学硕士（计算语言学 / NLP）｜广州
把模型能力落实为可运行的 Agent 工作流
我围绕 RAG、Tool Calling、结构化校验和人机协同，构建可解释、可测试、可回退的 AI 应用原型；同时具备企业 AI 付费交付、Java 服务端 Agent 原型和模型任务评测经验。
Application Stack
RAG
Tool Calling
LangGraph
Java / Python
企业 AI 有偿交付
5 个代号模型 × 3 类任务
6/6 Agent Gateway 测试通过
RAG / MCP 最小协议实验
ClawHub 7 个 Skills 合计 3,800+ 下载
Capability & Evidence Map
四类开发能力，分别由项目证据支撑
从应用架构、工具调用、检索和评测四个层面了解项目实践。
02
工具调用与安全边界
使用白名单、Schema、只读环境、人工审批和审计记录控制执行风险。
03
RAG 与协议实验
实践文档切分、召回、重排和最小 MCP 工具协议，保留可复核测试记录。
04
交付与质量验证
具备企业 AI 付费交付、Java 服务端原型和模型任务评测经验。
Primary Case · Paid Enterprise Delivery
企业年报文本分析：从模糊需求到可独立运行的交付
有偿外部委托｜独立设计与开发｜客户独立运行后验收付款｜客户资料保密
From vague request to accepted delivery
NLP · Batch Processing · Windows GUI · Excel / CSV · Client Handover
Delivery Path
业务问题从年报中筛选指定主题语句并标注情感，供投研人员整理与辅助判断。
单企业 MVP先验证文本处理、主题语句筛选、句级情感分类和结果导出链路。
批处理迭代扩展为年报或 ZIP 批量输入，并调整多企业结果字段与统计口径。
运行环境适配封装 Windows GUI，处理依赖、运行报错与网络问题，并提供演示和操作指南。
独立运行与验收客户按指南完成批量处理和结构化导出，随后验收并付款。
我把模型能力做成了非技术用户能够独立使用的交付物
客户需要从若干上市公司年报中筛选指定主题语句并识别情感态度，但没有指定技术实现。我负责把重复性文本处理收束为可批量输入、可结构化导出、可由客户独立操作的桌面工作流。
- 问题定义将“人工筛读年报”拆成处理对象、主题语句筛选、句级情感标注、批量输入和结构化输出，定位为投研信息整理工具。
- MVP 与迭代先完成单企业版本，再根据实际使用需求扩展多企业批处理，并调整 XLSX 导出字段与统计口径。
- 交付形态根据客户的 Windows 使用环境，将处理流程封装为可直接操作的桌面 GUI，并配套演示与操作指南。
- 运行支持处理批量运行慢、报错和网络等使用问题，重新封装运行环境并补充演示与操作指南。
- 完成结果客户能够按指南独立完成处理和 Excel / CSV 导出，项目随后完成验收并付款。
项目定位工具为投研信息整理和人工研判提供结构化输入，最终投资判断由使用者完成。
查看项目说明与验证记录
Product Judgment
三个信号，决定边界、纠偏与停止
功能完成只是一个信号；还要判断哪里会错、谁来兜底，以及证据是否支持继续扩围。
从评测信号到工程取舍
每个判断都保留四个要素：初始做法、偏差信号、纠偏动作与可复用原则。
01Evidence is not a violation
证据缺失，不等于业务违规
预检阶段判断证据能否进入规则审核，最终审批由费用会计负责。
偏差信号早期规则把附件缺失与已证实违规一起归入
REJECT。纠偏动作将缺失、冲突与待核实证据改为
FLAG，输出补证或人工核实动作。固化原则用 T10 回归测试固定分流规则：证据不足进入
FLAG，审批结论继续由人工负责。职责分工：预检输出证据状态与补证建议，人工负责审批与付款决定。
02Passing tests is not expansion readiness
边界测试通过，不等于可以扩大自动化
12/12 条边界测试通过，只能证明关键规则被实现；30 条标注样本的决策准确率为 63.33%，低于预设 80% 门槛。
偏差信号工程测试结果与业务样本表现出现明显落差。
工程取舍保留人工复核与只读流程，先补充样本和边界验证。
下一步先补齐只读采集、样本评测与人工抽查，再重新判断自动化范围。
工程取舍：评测结果低于门槛，当前范围保留人工复核。
03Executable is not safe
SQL 可执行，不等于语义与权限安全
查询即使能生成执行计划，仍可能包含无关联 JOIN 或触及敏感字段；因此可执行性不能代替风险判断。
偏差信号缺少关联条件的 JOIN 仍能通过执行计划检查，却可能产生笛卡尔积。
纠偏动作将 AST 校验、人工审批与只读运行环境放到执行之前。
固化原则模型只提出候选；规则、权限与人工共同决定是否执行，并保留有限重试和审计。
完成内容：在 SQLite 示例数据库中验证 AST 校验、人工审批、只读执行、有限重试与审计链路。
Implementation Evidence
支撑 Agent 开发的六组实现证据
每项只回答三件事：任务是什么、关键判断是什么、目前有什么可复核结果。
Agent GatewayGuardrails · Trace · Failure Handling
把“模型会调用工具”落实为受控服务链路
任务：验证 Tool Calling 的接口契约、白名单工具、有限轮次、失败分类与 trace。
判断：模型只提出调用意图，服务端决定工具权限与执行边界。
- 状态
- Java 21 / Spring Boot 3
- 验证
- 编译通过 · 6/6 测试通过
- 完成
- 接口契约、适配层与测试链路
协作雷达Schema · Validation · Safe Export
让非结构化协作材料进入稳定字段契约
任务：将会议纪要与群聊记录整理为七模块状态卡片。
判断：上游抽取可以不稳定，但来源、脱敏、Schema 校验、冲突检测与安全导出必须由确定性流程兜底。
热度榜第 1 · Top 1/1851 · 待公示协作雷达 Skill｜科大讯飞 Skill 比赛（智能办公协同助理方向）；最终结果以官方公示为准。
查看项目说明与中英文 Skill
- 实现
- Python · YAML · Schema
- 验证
- 坏 JSON 与注入用例自测
- 产出
- CSV / 飞书 / Notion 字段映射
WeRead AI BrainExternal Data · Analysis · Export
把阅读数据接入分析与 Markdown 导出流程
任务：连接用户授权的微信读书数据，完成可视化、概念分析与结构化导出。
判断：公开仓库需要把依赖、密钥配置和运行方式讲清楚，才能形成可复现入口。
- 状态
- GitHub 开源 · Skill 发布
- 输入
- 用户自行配置 API Key
- 产出
- 可视化与 Markdown
模型任务评测Failure Modes · Tool Use · Verifiability
用失败标签检查模型能否完成复合任务
我在 OpenClaw 与 Hermes 两种执行环境下，对 5 个代号模型执行 3 类复合任务，记录工具调用、文件处理、代码执行、数据分析与产物保存表现。
- 不以回答流畅度替代任务完成；识别上下文丢失、工具链路中断、产物格式不一致等失败模式。
- 关注结论是否有数据支撑、失败能否恢复、结果能否被用户验证。
代号说明公开页沿用评测记录中的模型代号，重点呈现任务完成与失败类型，不作通用模型排名。
查看任务范围与项目说明
- 形式
- 模型任务评测
- 范围
- 5 个代号模型 · 3 类任务 · 2 种环境
- 产出
- 失败模式与 Badcase 判断
科学营养顾问 SkillProfiles · Logs · Safety Boundaries
把一次性建议整理为可持续使用的 Skill 流程
我将营养咨询拆为用户档案、目标计算、每日记录、进度看板、场景建议与周期复盘，覆盖 12+ 健康管理场景（公开产品说明），并设置特殊人群与健康安全提示。
- 完成中英文版本与公开发布。
- 讯飞 Skill 比赛二等奖（官方公示）。
- 状态
- 公开发布
- 范围
- 12+ 场景 · 中英文版本
- 证明
- 状态设计与产品化闭环
RAG & MCPRetrieval · Protocol · Tool Use
用可运行实验验证检索方案与工具协议
我用 LangChain 与 LlamaIndex 分别实现 RAG 管线，对照切分、Dense + BM25 召回与 RRF 重排；同时用 Python 标准库实现 JSON-RPC 2.0 over stdio 的最小 MCP server。
- MCP server 提供 2 个工具；自建 client 完成
initialize、tools/list与tools/call冒烟测试。 - 验证覆盖协议握手、工具发现，以及自建 client 对 2 个工具的调用链路。
- 形式
- 检索管线与协议实现
- 范围
- 双框架 RAG · 2 个 MCP 工具
- 产出
- 可运行管线与协议测试
Product Principles
我如何判断一个 AI 方案值得继续做
三条原则分别约束问题定义、人机责任与扩围决策。
01
先定义任务结果与失败
明确用户、流程、完成标准和失败类型，再判断是否需要引入 AI。
02
分开模型、规则与人工责任
模型提出候选，规则拦截确定风险，人工对高风险业务动作负责。
03
用评测和外部证据做工程取舍
预先设定门槛与验证条件，让样本表现、测试和真实交付影响实现范围。
Next Conversation
如果你的团队正在把 AI 能力落进真实业务流程
我希望参与 AI 产品的需求拆解、评测标准定义与交付闭环，把模型能力转化为可验证、可协作的人机工作流。