上个月一个团队找我聊数字员工落地。
他们已经有 12 个 agent 在跑了。销售助手、客服助手、HR 问答、会议纪要……每个都是独立项目，独立部署，独立维护。
CTO 说：「我们想扩到 200 个。」
我问：「现在 12 个的权限怎么管的？」
他愣了一下：「每个 agent 一个 API key，配在环境变量里。」
「记忆呢？A 部门的 agent 会不会读到 B 部门的会议纪要？」
「……应该不会吧。」
「两个 agent 对同一件事判断冲突了，谁说了算？」
沉默。
12 个靠人盯，200 个靠什么？
而且这 12 个跑在半年前的模型上。模型半年一换代，agent 策略周级迭代——你还没把 12 个理顺，底座已经换了。这不是「多部署几个」的问题。这是架构问题。
上个月一个客户请我们做数字员工。
老板看完 demo，很兴奋。大模型能写邮件、做总结、回答制度问题，他觉得万事俱备。
「给销售、采购、客服各配一个数字员工，下个月上岗。」
工程师于是创建了几个角色，写了几段提示词，把聊天窗口换成了公司 Logo。
数字员工似乎就诞生了。
星期一早上，销售总监问它：「今天该先跟哪个客户？」它不知道。采购问它：「这批货该不该拒收？」它不知道。客服问它：「这个投诉要不要升级？」它也不知道。
老板很失望：「不是说好什么都会吗？」
什么都会。这四个字，是数字员工项目最常见的死因。
上周面试一个候选人。简历很漂亮——三年 LLM 应用开发，做过 RAG、做过 Function Calling、做过多轮对话系统。
我问他：「你平时自己写代码用什么工具？」
他说：「IntelliJ，偶尔用 Copilot 补全。」
我又问：「你上周的工作流是什么样的？从接到需求到交付。」
他想了想：「看需求文档，设计方案，写代码，联调，测试，上线。」
我说：「这个流程里，AI 在哪个环节？」
他愣了一下：「……写代码的时候用 Copilot。」
技术没问题。但他自己的工作流和五年前一模一样。
那一刻我就知道，他做不出好的 Agent 系统。 一个自己都不是 AI 驱动工作方式的人，设计不出 AI 驱动的产品。
