AI AGENTS & WORKFLOWS

AI Agent 与工作流自动化

真正有用的问题不是“AI 能不能做”，而是“哪一步应该让 AI 做、哪一步应该由软件约束、哪一步必须继续由人负责”。

我更关注 repeatable operational work，而不是为了做 chatbot 而做 chatbot。一个真正有用的 AI workflow 应该能接收输入、在明确范围内 reasoning、调用工具、输出结构化结果、把 exception 交给人，并且可以在相似 deployment 中越来越便宜地复用。

发布于 2026 年 9 月 9 日更新于 2026 年 10 月 6 日Shuo (Danny) Zhang

核心问题

真正需要回答清楚的问题

AI Agent 和 chatbot 有什么区别？

Chatbot 主要是 conversational interface。Agent workflow 也可以使用对话，但还可以读文件、分类输入、调用工具、更新系统、创建 structured records、触发后续动作，并把 exception 自动 route 给合适的人。

什么让一个 AI Agent 真正接近 production-ready？

可靠性主要来自模型外面的系统：受约束的 input/output、validation、需要时的 idempotency 或 deduplication、auditability、error queue、retry/recovery rules、permission boundary、monitoring，以及明确的 human escalation path。

哪些地方应该保留 human review？

当错误成本高、policy 有歧义、context 不完整，或者 decision 会对其他人产生实质影响时，应该保留明确的人类 ownership。Human review 应该是 workflow 设计的一部分，而不是出错后才临时补上。

什么事情不应该因为 AI“能试着做”就自动化？

不能因为模型能生成答案，就把 consequential decision 自动交给它。高影响 approval、irreversible action、模糊的法律/合规判断，以及 evidence 很弱的 exception，通常都需要 rule boundary 或 human decision。

为什么 reusable agent system 有商业价值？

真正的 leverage 来自把 reusable workflow core 和 client-specific configuration 分开。稳定的步骤、guardrails 和 integrations 被保留下来，而 field、routing rule、service area、threshold 等差异通过配置改变，后续 deployment 的成本才可能真正下降。

BUILT AGENT · 01

Medical Records Intake Agent

这是我第一个公开展示的 Agent demo：把收到的 medical-records request 转化成结构化、可以交给人 review 的工作。重点并不只是“把 PDF 里的字读出来”，而是把 intake、structured data、system update 和 human review 串成一个有边界的 workflow。

16 秒 workflow demo在 YouTube 打开 ↗

当前 demo 范围

从 incoming request 到结构化 human review

Agent 从 email 接收 request，解析 attached PDF，抽取病人和请求相关的关键字段，把结构化数据写入 Google Sheets，再把 case 交给 human reviewer 做核验和下一步处理。

Email request→PDF attachment→AI extraction→Google Sheets→Human review

这是更大 Production Agent Architecture 的第一个 vertical implementation：底层可以逐步复用 parsing、validation、rules、tool execution、exception handling、auditability 和 human-in-the-loop control。

已经展示的 workflow

Email intake、attachment parsing、structured field extraction、spreadsheet update，以及清楚的 human-review handoff。

系统边界

Agent 负责准备和 route 工作；需要核验或对下游产生影响的 decision，继续保留明确的人类 ownership。

可复用方向

Medical Records 是 Agent 01，而不是一次性的 demo。后面的 Agent 可以复用同一条 operational spine，只替换 domain rules、tools 和 integrations。

公开展示边界：这个视频用于展示 workflow，不构成 HIPAA certification 或 compliance 的宣称。公开 portfolio demo 不应暴露真实病历或其他 private source data。

ORIGINAL OPERATING MODEL

Reusable core，configurable edge

我认为最值得复用的商业机制，不是“每个客户都重新做一个 chatbot”。更好的方式是先把一个 recurring workflow 学透，把稳定部分编码一次，再把 fields、routing rules、service areas、integrations、thresholds 和 copy 等差异移动到 configuration。

先选一个重复发生的 workflow

从一个足够窄、但出现频率足够高的 operational job 开始。

画出 deterministic spine

先区分哪些事情软件可以 deterministic validate/route，哪些才真正需要 model reasoning。

只加入 bounded AI

给模型明确任务、structured output 和 limits，而不是开放式 authority。

先设计 exception

提前定义 duplicate、missing data、failed attachment、tool error、low confidence 和 human escalation。

把变化移动到 configuration

核心 workflow 保持稳定，用配置适配不同客户，而不是从零重建。

FIRST-PARTY WORKFLOW PATTERN

我正在实践的一种 workflow pattern

我实际做过的一种 intake pattern 是：email/PDF intake → document extraction → structured JSON → spreadsheet 或 downstream record → error queue。真正重要的不只是 extraction accuracy，还包括 deduplication、recoverability、attachment rules、可追溯的 source data，以及文档不完整或 malformed 时系统应该怎么走。

BOUNDARIES

我会明确保留的设计边界

当存在 authoritative source 或 deterministic system 时，model 不应该被当成 source of truth。
一个成功 demo 不等于 production workflow；recovery、logging 和 exception path 同样重要。
只有当 error cost 与 evidence quality 足够支持时，agent autonomy 才应该提高。
Reusable 不等于 universal。好的 vertical core 仍然需要 domain-specific configuration 与 constraints。