LangGraph 现在提供了 1 条专门的数据通道：后端可发送任意可序列化对象，前端按事件实时消费。它说明 Agent（能自主调用工具、分步骤完成任务的 AI 应用）开发已从“框架能跑”进入“交互细节可控”的阶段。
这是什么
这套机制解决的是 Agent 执行过程中的状态传递。比如搜索开始、搜索完成或进度百分比，不适合塞进对话消息，因为它们不是用户或模型说的话，而是应用运行事件。
基本链路是：后端节点调用 get_stream_writer() 写入数据；图模块注册 CustomTransformer，确保自定义事件被保留并转发；前端通过 useChannel 订阅，并从 params.data 读取内容。
其中有两个容易踩坑的地方：一是注册函数必须出现在 langgraph.json 所指向图模块的命名空间，否则写入的数据不会生成前端事件；二是 graph.invoke() 的本地运行不会把自定义事件推给前端，必须使用支持该流模式的运行方式。
行业怎么看
我们认为，这项能力的重要性不在于多了一条技术捷径，而在于 Agent 产品终于可以区分“对话内容”和“运行状态”。企业可以据此设计进度条、任务面板、审批节点和风险提示，而不必把所有信息伪装成聊天记录。
但风险也很明确：配置分散在图模块、流协议和前端订阅之间，命名遗漏、事件顺序错误、重复回放都可能造成难以定位的问题。replay 可以补接历史事件，适合状态展示，却也可能在操作失误后重复弹出通知；bufferSize 过大占用内存，过小则可能漏掉事件。
此外，自定义通道传的是任意对象，并不自动意味着安全、可审计或易于维护。涉及订单、付款、客户资料等关键状态时，企业仍需建立字段校验、权限控制与事件日志，不能把开发便利等同于生产可靠性。
对普通人的影响
对企业 IT：Agent 系统可以更清楚地展示后台进度，减少用户面对“正在思考”的黑盒等待；不过，团队也需承担事件协议、测试和日志治理成本。
对个人职场：未来工具可能更频繁地展示实时步骤，而不只是最后给答案。理解这一机制的人，将更容易判断流程卡在哪里、哪些环节仍需人工确认。
对消费市场：搜索、生成和自动化产品的过程提示会更精细，用户可能看到任务分解、资料检索及完成通知；代价是界面也可能因重复回放或过度展示技术细节而变得嘈杂。