最近我越来越强烈地感受到一种奇怪的技术回流。
Agent 和大模型发展得太快了，很多原本有软件开发能力的人，几乎下意识地开始把手里的系统“Agent 化”。以前需要设计服务、接口、状态机和后台任务，现在似乎只要在数据库上加一层 Agent，再准备几个工具，所有逻辑就都可以交给模型驱动。
与此同时，另一批人正在做相反的事情。随着 千问办公（QwenWork） 和 WorkBuddy 这样的个人 Agent APP 出现，非研发人员也可以用自然语言组织数据、生成文档、分析表格、搭建网页、连接办公工具，逐渐形成自己的个人工作台。
工程师正在尝试绕过一部分传统软件开发，普通人却因为 Agent 第一次拥有了组合软件能力的机会。
一边是工程师希望把软件变成 Agent，另一边是普通人开始用 Agent 搭建属于自己的软件。
工程师把软件变成 Agent，普通人用 Agent 重新组合软件，两条路径正在相向而行。
数据库上加一层 Agent，不等于完成了系统
Agent 最容易制造一种错觉：过去复杂的业务逻辑，现在都可以通过对话来完成。
例如，用户说“帮我处理这批订单”，Agent 可以读取数据库，调用支付接口，修改订单状态，再生成一份报告。演示的时候，这一切非常自然。它甚至比传统后台更像“产品”，因为用户不需要学习菜单、表单和操作步骤。
但这里有一个经常被忽略的问题：Agent 能够执行一条流程，不代表它能够稳定地承载一套业务规则。
扣库存、计算账单、判断权限、处理审批和迁移订单状态，这些事情要求的是确定性、一致性、可审计和可复现。它们不应该因为上下文变化、模型版本变化或一句话的不同表达，就得到不同结果。
如果把这些逻辑全部藏进 Prompt，系统的结构就会变成这样：
数据还在数据库里
规则藏在 Prompt 里
行为发生在上下文里
错误变得难以复现
这并不是软件工程消失了。恰恰相反，权限、状态机、幂等、事务、测试、监控和回滚仍然存在，只是被推到了更不容易看见的地方。
Anthropic 在《Building effective agents》中也给出了类似的提醒：先使用最简单的方案；确定性的任务优先使用工作流；只有在需要灵活决策和动态选择工具时，才引入 Agent。框架可以降低接入成本，但额外的抽象层也可能让底层调用和错误更难理解。
所以，“数据库加 Agent”可以是一个很好的交互层和编排层，却不能自动成为业务系统的全部架构。
Agent 处理不确定性，系统守住确定性
传统软件和 Agent 并不是谁取代谁的关系。更准确的分工是：
- Agent 处理模糊输入、非结构化信息和开放式目标；
- 传统系统保存可信数据、确定规则和业务状态；
- API 和工具把两者连接起来，并约束 Agent 可以做什么；
- 人负责定义目标、授权范围以及最终责任。
一份会议纪要适合交给 Agent 整理，一笔付款是否允许执行则需要明确的策略和审批。一堆合同适合交给模型提取信息，合同金额是否可以写入财务系统，则应该经过可验证的规则。
Agent 更像一个灵活的入口，而不是所有逻辑的最终归宿。它可以理解人的意图、寻找需要的信息、组合不同工具，再把确定性的动作交还给原有系统完成。
真正成熟的 Agent 系统，不是“让模型什么都能做”，而是让模型知道什么事情可以自主完成，什么事情必须调用确定性的服务，什么事情必须停下来等待人确认。
Agent 扩大系统处理不确定性的能力，企业系统守住确定性的边界，人承担最终责任。
普通人搭建的不是下一个企业系统
再看千问办公和 WorkBuddy，就能理解另一种变化。
它们已经不只是回答问题。千问办公强调从任务到交付，可以处理文档、表格、演示文稿和网页，也可以连接企业 IM 与外部数据源；WorkBuddy 则把办公 IM、文档、邮箱、会议、知识库和腾讯生态连接到同一个 Agent 入口。
这类产品更接近一个面向个人和岗位的工作台。使用者不需要先学习编程语言、数据库和 API，只需要描述自己想完成的任务，再通过文件、Skill、工具和不断调整的指令，组合出一套适合自己的工作方式。
过去，一个非研发人员想做这样的工具，通常需要找开发、提需求、排期、测试，再等待上线。由于需求足够个性化、使用人数又少，这类需求往往永远排不上优先级。现在，他可以先让 Agent 读取每天的材料，整理客户动态，分析经营数据，生成汇报，再按照自己的习惯不断调整过程。
但这并不意味着他正在建设一套新的 CRM、ERP 或项目管理系统。
个人工作台的价值恰恰在于“个人”。它服务一个人的角色、习惯和当前任务，可以快速变化，可以只使用一次，也可以长期只被一个人使用。它没有必要为了证明自己足够成熟，就增加完整的产品设计、多人权限、统一流程和复杂发布机制。
Excel 里的个人表格、浏览器里的书签、自己写的一段脚本，从来没有因为足够有用，就必须升级成企业软件。Agent 工作台也是一样。
个人工具可以永远是个人工具。它的目标是提高一个人的工作效率，而不是成为下一个生产系统。
个人工作台的上限，取决于它能连接什么
个人工作台不需要变成生产系统，不代表它可以脱离生产系统独立工作。
一个只能够使用公开互联网和用户临时上传文件的 Agent，当然可以写文章、总结资料、生成 PPT。但如果它不知道我今天开了什么会，不知道客户最近提出了什么问题，看不到项目当前的任务，也无法读取企业知识库和经营数据，它就很难真正参与我的日常工作。
个人工作台的价值不只来自模型，而是来自它能够接近多少真实、连续的工作上下文。
个人 Agent 越想提高效率，就越需要接近真实的工作现场：
- 从企业 IM、邮件和日历中理解每天发生了什么；
- 从文档、知识库和网盘中找到正确的背景材料；
- 从 CRM、ERP、财务和项目系统中读取当前业务状态；
- 连接搜索、行业数据库和外部 SaaS，补充企业之外的信息；
- 在获得授权后创建任务、更新日程或发起一个正式流程。
这时候，真正限制 Agent 的往往不再是模型够不够聪明，而是企业内部的数据孤岛有没有被打通，旧系统有没有可以稳定调用的 API，身份和权限能不能正确传递，外部服务能不能被统一接入。
很多企业表面上已经有了几十套数字化系统，但每个系统都有自己的账号、数据结构和操作界面。人可以在它们之间复制粘贴，Agent 却很难在缺少接口和权限模型的情况下可靠地完成工作。
所以，个人工作台背后真正需要建设的，可能不是更多聊天框，而是一层面向 Agent 的企业能力接口：把分散的数据、API 和操作封装成可以发现、可以授权、可以审计的 Tool 或 Skill。
个人 Agent 工作台
↓ 理解、分析、编排
企业 Tool / API / Skill 层
↓ 身份、权限、审计
企业内部系统 + 外部服务
个人工作台保持轻量，Tool、API 和 Skill 连接层负责把身份、权限、审批、审计与回滚守住。
有了这一层，每个人才可能在不重新开发企业系统的前提下，组合出属于自己的工作台。
连接生产系统，不等于成为生产系统
这里最容易混淆的是：一个个人 Agent 连接了生产系统，是否意味着它自己也必须变成生产系统？
我认为不是。
个人 Agent 从 CRM 读取客户信息，整理出今天需要跟进的客户，它仍然只是个人助手；从多个项目系统提取进度，生成一份只给自己看的日报，它也仍然是个人工具。
真正需要严肃对待的，不是这个工作台有多少用户，而是它正在执行什么动作。
| Agent 行为 | 个人工作台可以自主完成 | 需要正式系统约束 |
|---|---|---|
| 搜索、汇总和整理信息 | 可以 | 做好访问控制 |
| 生成分析、建议和草稿 | 可以 | 保留来源和依据 |
| 创建个人待办、预约日程 | 通常可以 | 沿用用户本人权限 |
| 修改客户、订单等业务状态 | 不宜自行决定 | 调用确定性 API |
| 付款、审批、删除关键数据 | 不可以直接执行 | 审批、审计和回滚 |
| 改变团队共享流程 | 不属于个人配置 | 进入正式发布和治理 |
边界不应该简单画在“个人工具”和“生产系统”之间，而应该画在只读与写入、建议与决策、无副作用与有副作用之间。
个人工作台可以保持轻量和灵活，但它调用企业能力的连接层必须足够严肃：使用谁的身份，能访问哪些数据，调用了什么接口，产生了什么结果，失败后如何恢复，都应该能够被清楚回答。
换句话说：
个人工作台不需要生产级产品化，但它与生产系统之间的连接必须接受生产级治理。
未来的软件，可能会分成两层
过去的企业软件试图为所有人设计统一界面。产品经理收集共性需求，研发把它们做成菜单、表单、按钮和固定流程，再让所有员工学习同一种使用方式。
但真实工作中，每个岗位甚至每个人需要的信息和操作顺序都不一样。销售关心客户变化，项目经理关心风险和依赖，管理者关心经营指标，工程师关心任务、代码和系统状态。传统软件只能优先满足共性，很难为每个人维护一套界面。
Agent 带来了一种新的可能：企业不再为每一种个人习惯开发一个独立应用，而是把稳定的数据和业务能力开放出来，让每个人通过 Agent 动态组合自己的入口。
未来的软件可能逐渐分成两层：
- 稳定的企业能力层：保存正式数据、业务规则、权限、状态和审计记录。
- 个性化的 Agent 工作层：围绕每个人的目标，理解信息、组合工具并生成交付物。
下面一层追求稳定、确定和可治理，上面一层追求灵活、个性化和低门槛。个人 Agent 不需要复制一遍企业软件，只需要在获得授权后使用企业已经提供的能力。
这样看，普通人所谓的“重新开发软件”，并不是重新建设一套生产系统，而是在既有系统之上重新组织自己的工作方式。
真正值得建设的，是开放而受控的系统边界
这场技术回流最终提出了两个不同的问题。
对于工程师来说，问题是：哪些能力可以交给 Agent 灵活编排，哪些规则必须继续留在确定性的系统里？
对于普通人来说，问题是：能否不再等待一个统一产品满足所有需求，而是利用 Agent、数据和工具，为自己搭建一套真正贴合工作的个人工作台？
这两件事并不冲突。它们最终会在同一个地方相遇：企业系统是否拥有开放而受控的边界。
如果企业系统没有 API，数据继续困在孤岛里，Agent 再聪明也只能停留在写作和总结。如果企业为了接入 Agent，把数据库和关键操作毫无约束地暴露出来，灵活又会变成新的风险。
真正需要建设的，是一套既能被 Agent 使用，又能继承身份、权限、规则和审计能力的连接层。它让企业系统不必全部 Agent 化，也让个人工作台不必成长为一个沉重的软件项目。
工程师不需要放弃软件工程，普通人也不需要成为专业程序员。企业负责把稳定能力建设好，Agent 负责把能力组合起来，人则按照自己的目标使用它们。
Agent 没有要求每个人都成为一家软件公司。它只是让每个人都有机会在企业能力之上，拥有一套真正属于自己的软件。