Agent 上线，比 Demo 难十倍

用 Codex 做出一个不错的 Agent Demo 已经不难。真正难的是把它放进真实业务，让系统敢为每一次结果负责。

我最近在做一个社媒运营 Agent，想解决中小企业没钱、没人专业运营账号的问题。

大公司可以养一支团队，研究市场、制定策略、写内容、做设计。中小企业往往只能让老板或某个员工顺手发几条，忙起来账号就停在那里。

Agent 给了这件事一种新可能。以前要雇一群人完成的工作，现在可以先「雇」一支 AI 团队：它理解公司和客户，规划内容，再完成选题、文案、配图和发布。用户不必执行每一步，只在关键地方做判断——方向对不对，这是不是我想说的，能不能代表公司发出去。

这套东西用 Codex 做 Demo，比我预想中容易得多。给它一些公司资料、目标客户和参考内容，它很快就能写出一篇像样的帖子，配好图片，再放进发布队列。整个流程跑起来，已经很有产品的样子。

可当我真想把它交给用户，工作量突然大了一个数量级。

如果一定要给这种体感一个数字，我会说：做一个能上线的 Agent，至少比做同等规模的传统软件难十倍。

一篇好帖子，只是一个样本

Demo 里的题目通常是准备好的。资料比较完整，目标也很清楚；模型写偏了，我可以换种说法再试，几个版本里总能挑出一篇不错的。

真实用户不会这样配合。他可能只说：「最近想聊聊 Agent，别太像行业报告。」

Agent 要自己判断写什么、参考哪些材料、用户真正认同什么，以及「别像行业报告」具体是什么意思。换个话题，调整一下上下文，结果都可能变样。

更关键的是，用户需要的不是某一次灵光乍现，而是在接下来几周里稳定发出一批内容。它们不能互相重复，语气要像同一个人，还要跟得上业务变化。

一篇好帖子只能说明系统成功过一次。上线要面对的是接下来每一次。

Agent 会正常地做错

传统软件上线也很麻烦，要补权限、异常、性能和监控。但它的大部分行为由人提前写好：点哪个按钮，进入什么状态，接口成功后发生什么，规则相对明确。

Agent 多了一层运行时判断。

一篇帖子最后写成什么样，会同时受到模型、用户资料、历史内容、检索结果和工具返回值影响。工程师没有写下每一个分支，也不可能提前看过所有结果。

于是会出现一种很麻烦的错误：模型正常返回，图片生成成功，发布接口也没有报错，可它写下的观点并不属于用户，引用的数据已经过期，或者同一个结论上周刚发过。

从技术监控看，一切正常。从业务角度看，这篇内容根本不该发。

传统软件的很多错误会报错，Agent 的错误常常藏在意思里。系统除了检查「有没有执行成功」，还得判断「做的事情对不对」。后面这件事，没有一个状态码能告诉你。

Demo 里藏着一个人

很多 Agent Demo 看起来是自动完成的，背后其实一直有人在帮忙。

演示者会挑选适合的题目，补充缺失的背景，第一版不好就重新生成，再从几个版本里选出最好的一篇。最后还要检查事实、语气和品牌风险。

Agent 负责生成，人仍然负责理解、筛选和验收。

真正上线后，这些工作不能继续靠演示者临场发挥。系统要知道什么时候追问，哪些信息必须核实，哪些内容需要用户确认。它还要记住用户改了什么，同时分清这是长期偏好，还是只适用于这一次。

我想做的「用户只负责判断」，也不是简单地把人移出流程。人的位置变了：从反复执行，退到少数真正需要品味、业务常识和责任的节点上。

时间和发布，会把偶然错误放大

单篇内容看不出的问题，连续运营很快就会暴露。

选题开始重复，语气越来越像模板，旧内容与新观点互相打架。公司的业务重点会变，参考资料会过期，模型和平台规则也一直在更新。

发布还会改变外部状态。草稿写错了可以重来，内容一旦发出去，已经产生的阅读、截图和印象很难完全撤回。

这时，评价 Agent 不能只看平均写得好不好，还要看它偶尔犯错时会替用户说出什么，系统能不能在发布前把它拦下来。

Demo 跑几次，很容易只看到能力。生产环境运行得足够久，那些低概率的问题迟早都会遇到。

上线的工作，大多在模型外面

一个演示级 Agent 能生成内容、调用工具，就足够让人眼前一亮。真正上线，还要补上几件不那么酷、却更重要的事：

• 目标要清楚：不能只看生成了多少，还要看用户愿意发布多少、修改多少，事实错误和内容重复出现了多少。
• 质量要能检查：重要信息要有来源，内容要与历史观点一致，不确定的地方要主动露出来。
• 权限要有边界：选题和草稿可以更自主，敏感表达与最终发布需要更严格的确认。
• 失败要能收场：平台超时、定时失败、重复发布和错误内容，都要有明确的处理方式。
• 过程要能还原：一篇帖子用了什么资料、经过哪些修改、由谁确认、最终发布了哪个版本，都应该查得到。

这些能力都不在模型本身里面，却决定了我们敢不敢把账号交给 Agent。

做到这里我才真正理解，Demo 并不是生产系统的缩小版。它更像一次能力展示：先让你看见这件事可能发生。接下来的产品工作，是给这种能力补上边界、检查和兜底。

下一篇，讲怎么把它做出来

这篇说的是为什么难，下一篇我想继续写：一个生产级 Agent 到底应该怎么做。

我一直很喜欢 Anthropic 那篇 《Building effective agents》。它没有把 Agent 讲成越复杂越高级的东西，给出的建议反而很朴素：先找到最简单的可行方案，只有结果确实变好时才增加复杂度；明确的任务交给固定工作流，需要灵活判断的地方再交给 Agent。

这个判断放到社媒运营里特别实用。哪些步骤应该写死，哪些可以让模型决定？用户应该在哪些地方出现？怎样检查一批内容是真的越来越好，而不是越来越像？

这些是我接下来想拆的问题。

Demo 让人看到 AI 会什么。真正的产品，要让人敢把账号交给它。