Six Things Enterprise Architects Get Wrong About the Operational–Analytical Chasm — and How to Close the Agentic Loop企业架构师在“操作与分析鸿沟”上的六大误区——以及如何闭环智能代理
The operational–analytical chasm is where agentic strategies go to die.操作与分析之间的鸿沟，是代理式（agentic）战略走向失败之地。
Saša MitrovićSaša Mitrović
For the better part of thirty years, the reference architecture for data has looked the same: an operational database on one side, an analytical warehouse on the other, and a pipeline in the middle moving data from where it’s written to where it’s analysed. We’ve built careers on that diagram, and we’ve stopped questioning it.在过去三十年的大部分时间里，数据参考架构几乎一成不变：一边是操作型数据库，另一边是分析型数据仓库，中间通过管道将数据从写入端搬运到分析端。我们凭借这一架构蓝图建立了自己的职业生涯，也因此停止了对它的质疑。
It’s worth questioning now. The arrival of AI agents that don’t just read data but act on it has exposed the chasm for what it always was — a workaround for a hardware limitation, not a principle of good design.现在是时候质疑了。AI 代理的出现——它们不仅能读取数据，还能基于数据采取行动——彻底揭示了这条鸿沟的本质：它始终只是硬件局限性下的权宜之计，而非优秀设计的原则。
Most of the architectural mistakes I see teams make here come from defending the workaround instead of the goal. Here are the six that matter most.我观察到团队在架构上犯的大多数错误，都源于他们是在维护这种“权宜之计”，而非实现目标。以下是其中最关键的六个误区。
For decades, the separation between operational (OLTP) and analytical (OLAP) systems was a hard technical constraint. Transactional databases were tuned for many small concurrent reads and writes. Think Uber where millions of customers are hailing a ride or riding at this moment. That’s powered by an OLTP database (let’s assume it’s one database, for simplicity).几十年来，操作型系统（OLTP）与分析型系统（OLAP）的分离是一项硬性的技术约束。事务型数据库专为高频的小规模并发读写而优化。以 Uber 为例，数百万用户在同一时刻打车或乘车，这正是由 OLTP 数据库（为简化起见，假设为一个数据库）支撑的。
Analytical engines were tuned for large scans and aggregations. Think of business analysts planning the next Uber expansion into a region. This kind of analysis is a series of sequential queries that span billions of raw of data.而分析型引擎则专为大规模扫描和聚合而优化。想象一下业务分析师在规划 Uber 下一个区域的扩张，这种分析通常涉及跨越数十亿行数据的连续查询。
You could not serve both patterns well from one engine mostly because of the economics of that. A single system like that, and there are vendors like SAP and Oracle who do offer those, is really very expensive and the investment is justified in rare cases only.你很难用同一个引擎同时处理这两种模式，这主要是经济成本的问题。虽然 SAP 和 Oracle 等厂商确实提供此类单一系统，但它们非常昂贵，只有极少数情况下才值得投入。
The economical solution is to run two separate systems, and you paid the cost of moving data between them: change data capture, ETL/ELT jobs, a streaming bus, a connector fleet, and a team to keep it all alive.经济的解决方案是运行两个独立的系统，并承担数据搬运的成本：变更数据捕获（CDC）、ETL/ELT 作业、流式总线、连接器集群，以及一个负责维护这一切的团队。
That cost became so normal we stopped seeing it as a cost. We started treating the pipeline as architecture — a thing with inherent value — rather than as overhead we tolerated because we had no alternative. We internalised the divide and built muscles to handle it.这种成本变得如此习以为常，以至于我们不再将其视为成本。我们开始把管道视为一种“架构”——一种具有内在价值的东西——而不是因为别无选择而不得不忍受的开销。我们内化了这种割裂，并练就了应对它的本领。
The agentic era is what makes this finally untenable. An AI agent embedded in your business doesn’t just want to read a dashboard.代理式时代的到来，终于让这种模式变得难以为继。嵌入你业务中的 AI 代理，可不仅仅是想看一眼仪表盘。
No, it also wants to observe the current state of the operational world, reason over it against everything else you (and hopefully it) know, and then act — place the order, flag the account, adjust the limit, write the decision back.不，它还需要观察操作世界的当前状态，结合你（以及它自己）所知的一切进行推理，然后采取行动——下单、标记账户、调整额度、将决策回写。
The old divide makes that loop slow and lossy: the agent reasons over data that’s hours stale because it came through a nightly pipeline, and it has no clean path to act back on the system of record. You cannot build a responsive agentic enterprise on a one-way street paved with brittle ETL. You can’t act just-in-time on stale data.旧有的割裂使得这个循环变得缓慢且存在损耗：代理基于过时数小时的数据（因为它是通过夜间管道传输的）进行推理，且没有清晰的路径将结果回写到记录系统。你无法在铺满脆弱 ETL 的单行道上构建响应式的代理企业。你无法用过时的数据实现即时行动。
So the chasm is finally collapsing — not because someone declared it obsolete, but because the workload that exposes it has arrived. Here are the six assumptions to drop on the way through.因此，这条鸿沟最终正在坍塌——不是因为有人宣布它过时，而是因为能够揭露它的工作负载已经到来。以下是你在跨越这一鸿沟时需要摒弃的六个假设。
Mistake 1: Believing the operational/analytical split is a law of architecture误区 1：认为操作与分析的分离是架构法则
The instinct that surfaces this: “Operational and analytical are just different worlds. You keep them separate. That’s how it’s done.”产生这种直觉的原因是：“操作和分析是两个不同的世界。必须将它们分开。一直以来都是这么做的。”
It’s so deeply ingrained that most architects treat it as a first principle rather than what it is: an accommodation. We separated the two because no single engine could serve transactional and analytical patterns at once cost-efficiently at scale, and that was true for a very long time.这种观念根深蒂固，以至于大多数架构师将其视为第一原则，而非其本质：一种妥协。我们之所以将两者分开，是因为在很长一段时间内，没有任何单一引擎能以经济高效的方式在大规模场景下同时满足事务处理和分析模式。
The architectural reality: It was never a design principle — it was a constraint we dressed up as one. The moment a platform can hold operational data with full transactional fidelity and expose a continuously synced copy for analysis, the separation stops being mandatory and becomes a choice. And a choice you keep making out of habit is technical debt you’re accruing on purpose.架构真相：这从来都不是设计原则，而是我们包装成原则的约束。当平台能够以完全的事务保真度存储操作数据，并提供持续同步的副本用于分析时，分离就不再是强制性的，而变成了选择。如果你继续出于习惯而做出这种选择，那就是在故意制造技术债务。
What good looks like: Start designing for convergence, not separation. Assume operational data can be available to analytics and AI natively — without you personally building the bridge — and ask what your architecture looks like when the gap between “where it’s written” and “where it’s analysed” shrinks to near zero. The teams that win the next decade will be the ones who stopped treating the divide as permanent and started treating it as a setting they can turn down.理想形态：开始为融合而非分离而设计。假设操作数据可以原生提供给分析和 AI 使用——无需你亲自搭建桥梁——并思考当“写入端”与“分析端”之间的鸿沟缩小到近乎零时，你的架构会是什么样子。未来十年胜出的团队，将是那些不再把割裂视为常态，而是将其视为可以调优的设置的团队。
The anti-pattern to avoid: Architecting your next platform around a constraint that no longer binds. You’ll spend the next three years building, scaling, and staffing the same two-estates-plus-pipeline pattern your predecessors did — and defending it in design reviews with reasons that were last true a decade ago.应避免的反模式：围绕一个不再适用的约束来构建你的下一个平台。你将花费未来三年时间去构建、扩展和配置与前人相同的“双 estate 加管道”模式，并在设计评审中用十年前的理由去为它辩护。
Mistake 2: Treating the pipeline as architecture rather than as a tax误区 2：将管道视为架构而非税负
The instinct that surfaces this: “What’s our CDC strategy? A streaming bus? A managed connector? A nightly batch?”产生这种直觉的原因是：“我们的 CDC 策略是什么？流式总线？托管连接器？还是夜间批处理？”
Every one of these is a reasonable question, and every one of them is answering the same need: how do I get a faithful, current copy of operational data into a place I can analyse it at scale? We’ve answered that need so many times that the machinery feels like part of the architecture. It isn’t. It’s the toll you pay at the border between two estates.每一个问题都很合理，且都在回答同一个需求：如何将操作数据的忠实、最新副本放入我可以大规模分析的地方？我们回答这个需求太多次了，以至于这些机器看起来像是架构的一部分。其实不然。这只是你在两个 estate 边界处缴纳的过路费。
The architectural reality: A pipeline produces no business value. It moves bytes. Everything you actually care about — the analysis, the model, the decision — happens on either side of it, never inside it.架构真相：管道本身不产生任何业务价值。它只是搬运字节。你真正关心的所有事情——分析、模型、决策——都发生在它的两端，从不在管道内部。
And the toll is expensive: pipelines break, they deliver stale data, they fail silently at 2am, and they require a standing team to operate. When a pipeline’s only job is shuttling your own first-party operational data across an internal boundary, every hour of latency and every broken job is pure overhead, not architecture.而且这笔过路费很昂贵：管道会中断、传输过时数据、在凌晨静默失败，并且需要专门的团队来运营。当管道的唯一工作就是将你自己的第一方操作数据跨越内部边界进行搬运时，每一小时的延迟和每一次作业失败都是纯粹的开销，而非架构。
A pipeline that genuinely transforms, cleanses, or enriches is doing real work — that’s a different conversation.当然，如果管道确实在进行转换、清洗或丰富数据，那是在做实际工作——那是另一个话题。
What good looks like: Make data movement a property of the platform, not a system you build and babysit. For first-party operational data, the bar should be: no bespoke pipeline. The data should arrive in your analytical plane natively, kept current automatically, with a refresh cadence you choose per workload. Reserve real pipeline engineering — connectors, streaming, orchestration — for the place it actually earns its cost: ingesting data from systems you don’t control, like third-party SaaS and external sources.理想形态：让数据移动成为平台的一种属性，而不是你需要构建和照看的系统。对于第一方操作数据，标准应该是：无需定制管道。数据应原生到达你的分析平面，自动保持最新，并根据工作负载选择刷新频率。将真正的管道工程——连接器、流处理、编排——留给真正能体现其价值的地方：从你无法控制的系统（如第三方 SaaS 和外部来源）摄取数据。
The anti-pattern to avoid: Standing up a CDC pipeline out of reflex to move your own operational data into your own analytics. It works on day one. Six months later you’re paying for a connector, debugging a schema-drift failure over the weekend, and explaining to finance why moving your own data across an internal boundary needs its own headcount.应避免的反模式：出于惯性建立 CDC 管道来搬运自己的操作数据。第一天运行良好，六个月后你就会发现自己在为连接器付费，在周末调试模式漂移故障，并向财务部门解释为什么在内部边界搬运自己的数据需要专门的人员编制。
Mistake 3: Misreading the freshness and consistency contract误区 3：误读了新鲜度和一致性契约
The instinct that surfaces this: “If the copy is synced, can I treat it like the live database? Read my own writes, serve from it, point the app at it?”产生这种直觉的原因是：“如果副本是同步的，我能把它当作实时数据库吗？读取我自己的写入、从它提供服务、让应用指向它？”
This is the question most likely to cause a production incident, because architects who’ve worked with synchronous replicas tend to assume any synced copy behaves the same way. It doesn’t, and the difference matters.这是最容易导致生产事故的问题，因为习惯了同步副本的架构师往往认为任何同步副本的行为都一样。事实并非如此，且差异至关重要。
The architectural reality: A continuously synced analytical copy is near-real-time and recent — updates land in seconds at the cadence you set — but it is asynchronous, not transactional. It reflects a consistent recent state, not the millisecond-current one.架构真相：持续同步的分析副本是近实时的、最新的——更新会在你设定的频率下几秒内落地——但它是异步的，而非事务性的。它反映的是一致的近期状态，而非毫秒级的当前状态。
That is exactly right for analytics, BI, and AI reasoning, where seconds-fresh is more than enough and large-scan performance is what you need. It is the wrong contract for low-latency serving and read-after-write guarantees, which still belong to the operational system of record.这对于分析、BI 和 AI 推理来说非常完美，因为秒级新鲜度已经足够，而大规模扫描性能才是你所需要的。但对于低延迟服务和“读后写”保证来说，这是错误的契约，这些需求仍属于操作记录系统。
The convergence collapses the distance between the two; it doesn’t erase the distinction between “the authoritative current state” and “a fast, recent analytical view.”融合缩小了两者之间的距离，但并没有抹除“权威当前状态”与“快速、近期分析视图”之间的区别。
A system of record is still a system of record.记录系统始终是记录系统。
What good looks like: Match each workload to the right surface, deliberately:理想形态：针对每个工作负载，明智地匹配正确的界面：
Set freshness per workload rather than reaching for the lowest possible latency everywhere — higher frequency costs more and most analytics doesn’t need sub-minute data.按工作负载设定新鲜度，而不是盲目追求最低延迟——高频率意味着高成本，且大多数分析并不需要秒级以下的数据。
The anti-pattern to avoid: Assuming “it’s all on one platform now, so it’s all real-time and interchangeable.” Point a latency-sensitive serving path at the analytical copy and the first time a user fails to read their own write — usually within days of going live — you’ll be reintroducing the very boundary you thought you’d erased, as an incident instead of as a design decision.应避免的反模式：假设“现在都在同一个平台上，所以全是实时的且可互换”。将延迟敏感的服务路径指向分析副本，那么当用户第一次遇到无法读取自己写入的数据时（通常在上线几天内就会发生），你就会被迫重新引入你以为已经消除的边界——这次它将以事故而非设计决策的形式出现。
Mistake 4: Treating operational and analytical as two governance estates误区 4：将操作和分析视为两个治理 estate
The question that surfaces this: “Who governs which side? How do we keep masking, access controls, and lineage consistent across both?”产生这种直觉的原因是：“谁来治理哪一边？我们如何保持两边的脱敏、访问控制和血缘关系一致？”
The question assumes the answer must involve reconciliation — two governance regimes you work to hold in sync. That’s a holdover from the era of two separate products owned by two separate teams.这个问题假设答案必须涉及协调——即你努力保持同步的两个治理体系。这是两个由不同团队拥有的不同产品时代的遗留物。
The architectural reality: Operational and analytical aren’t two estates; they’re one estate with two access patterns. Governance fragmented along the seam largely because the seam ran between two products — and in regulated environments, because no single platform could satisfy both access patterns under one policy regime.架构真相：操作和分析不是两个 estate，它们是具有两种访问模式的同一个 estate。治理在接缝处碎片化，很大程度上是因为接缝横跨了两个产品——并且在受监管的环境中，因为没有单一平台能在统一的策略体系下同时满足两种访问模式。
When operational data and its analytical copy live on the same platform, RBAC, masking and tokenization, classification, and lineage can be reasoned about as one surface — not two you manually keep in agreement. A column tagged sensitive can be protected everywhere it’s consumed, and the path from source table to analytical copy to downstream dashboard can be traced as one lineage graph.当操作数据及其分析副本位于同一平台时，RBAC、脱敏、标记化、分类和血缘关系都可以作为一个整体来考虑，而不是两个需要你手动保持一致的东西。被标记为敏感的列可以在所有消费端得到保护，从源表到分析副本再到下游仪表盘的路径可以作为一张血缘图进行追踪。
What good looks like: Govern once, at the platform level, spanning both patterns. The business that owns the system of record and its data also owns the governance over it downstream.理想形态：在平台层面统一治理，覆盖两种模式。拥有记录系统及其数据的业务方，同时也拥有对其下游的治理权。
One role model — don’t clone a parallel set of operational roles “for consistency,” which is just two things to drift apart. Classify and mask at the converged layer so protection follows the data. Treat the synced copy as a first-class lineage edge, not a black-box hop.设定一个角色模型——不要为了“一致性”而克隆一套平行的操作角色，那只会导致两边分道扬镳。在融合层进行分类和脱敏，让保护机制跟随数据。将同步副本视为一等血缘边缘，而不是黑盒跳跃点。
In regulated environments this doesn’t remove the controls a regulator requires — it lets you satisfy them from one policy surface instead of reconciling two.在受监管的环境中，这并不会移除监管机构要求的控制措施——它让你能在统一的策略表面满足这些要求，而不是去协调两个体系。
The anti-pattern to avoid: Duplicating masking and access policy across two stacks and calling it defence in depth. It isn’t depth; it’s divergence. One side gets updated when a regulation changes and the other doesn’t — and you discover the gap six months later, in an audit or after a disclosure.应避免的反模式：在两个堆栈中重复设置脱敏和访问策略，并称之为“纵深防御”。这根本不是纵深，而是分歧。当法规变更时，一边更新了而另一边没更新——六个月后，你在审计中或数据泄露后才会发现这个缺口。
Mistake 5: Treating the synced platform as a one-time setup, not an operated system误区 5：将同步平台视为一次性设置，而非运营系统
The question that surfaces this: “We turned it on and it works. We’re done, right?”产生这种直觉的原因是：“我们开启了它，它能运行。我们完成了，对吧？”
This is the question that separates teams who’ve run a replication system in production from teams who’ve only switched one on. Turning it on is the easy part.这个问题区分了那些在生产中运行过复制系统的团队，和那些只是开启过开关的团队。开启它只是最简单的部分。
This is also where it’s worth naming the concrete capability, because the principles above now have a real implementation. Snowflake Postgres runs fully managed Postgres instances inside Snowflake, and data mirroring replicates that operational data into Snowflake’s analytical engine natively, in near real time — no ETL, no connector, no glue code. You choose the replication frequency and let it run. Everything in the previous four sections is what it looks like in practice.这也是为什么值得命名具体能力的原因，因为上述原则现在有了真正的实现。Snowflake Postgres 在 Snowflake 内部运行完全托管的 Postgres 实例，数据镜像将这些操作数据原生、近实时地复制到 Snowflake 的分析引擎中——无需 ETL，无需连接器，无需胶水代码。你选择复制频率，然后让它运行。前四节中的所有内容，就是它在实践中的样子。
The architectural reality: A mirror is a living dependency between two systems, and living dependencies need operational discipline even when they’re managed. The source schema evolves. Freshness matters differently for different consumers.架构真相：镜像系统是两个系统之间活生生的依赖关系，而活生生的依赖即使在托管状态下也需要运营纪律。源模式会演变。新鲜度对不同消费者的意义也不同。
What good looks like: Wrap the mirror in the practices you’d apply to any production data dependency:理想形态：用你应用于任何生产数据依赖的实践来包装这个镜像：
- Freshness monitoring. Know your replication lag and alert on it. A dashboard that silently goes stale is worse than one that’s obviously down — people keep trusting it.新鲜度监控。了解你的复制延迟并设置告警。一个静默过时的仪表盘比一个明显宕机的仪表盘更糟糕——因为人们会持续信任它。
- Schema-change coordination. When the app team adds, renames, or retypes a column, that change reaches the analytical surface. Make it a coordinated event, not a runtime surprise.模式变更协调。当应用团队添加、重命名或更改列类型时，该变更会到达分析表面。让它成为一个协调的事件，而不是运行时的意外。
- Cadence and cost awareness. Set refresh frequency to the business need, not the technical maximum, and review it.频率与成本意识。根据业务需求而非技术极限来设定刷新频率，并定期审查。
- Named ownership. Every mirrored dataset needs a human owner accountable for its freshness and its schema contract. Ideally, it’s owned by the owner of the original system of record. Without that, maintenance becomes everyone’s job and therefore no one’s.明确所有权。每个镜像数据集都需要一个对其新鲜度和模式契约负责的人类所有者。理想情况下，它由原始记录系统的所有者拥有。没有这一点，维护就成了“每个人的工作”，最终变成“没人管的工作”。
The anti-pattern to avoid: “Set it and forget it.” You’ll forget it right up until the quarter-end number is wrong, and the root cause turns out to be a column renamed three weeks ago that quietly changed what a field meant. Managed infrastructure removes the toil of running a pipeline; it does not remove your accountability for the data contract riding on it.应避免的反模式：“设置好就忘掉它”。你会一直忘掉它，直到季度末数字对不上，而根本原因竟是三周前重命名的一列字段静默改变了含义。托管基础设施消除了运行管道的繁琐，但并没有消除你对承载其上的数据契约的责任。
Mistake 6: Thinking this is an analytics upgrade, when it’s really an agentic one误区 6：认为这是分析升级，实则是代理升级
The question that surfaces this: “This is great for our dashboards and our data team — but is it strategic?”产生这种直觉的原因是：“这对我们的仪表盘和数据团队来说很棒——但它具有战略意义吗？”
If you file converged operational-analytical data under “faster BI,” you’ve understood the feature and missed the shift. The dashboards are the small prize. The agentic enterprise is the big one.如果你将融合的操作-分析数据归类为“更快的 BI”，那你只是理解了功能，却错过了变革。仪表盘只是小奖励，代理式企业才是大奖。
The architectural reality: An AI agent is only as good as the loop it can close. To be useful inside your business, an agent has to do three things:架构真相：AI 代理的好坏取决于它能闭环的程度。要在你的业务中发挥作用，代理必须做三件事：
- observe the current operational state,观察当前的操作状态，
- reason over it against the rest of your data and context, and结合你的其他数据和上下文进行推理，以及
- act on the conclusion.基于结论采取行动。
The old divide breaks every part of that loop — the agent reasons over stale, pipeline-delayed data, and has no governed path to write its decision back to the system of record.旧有的割裂破坏了该循环的每一个环节——代理基于过时的、管道延迟的数据进行推理，且没有受治理的路径将决策回写到记录系统。
Converging operational and analytical data on one platform is what makes the loop tight: the agent reads operational truth that’s seconds old, reasons over it alongside all your analytical data, and writes its action back — on one governed platform, with no pipeline in the middle.在单一平台上融合操作和分析数据，是实现紧密循环的关键：代理读取秒级新鲜的操作真相，结合所有分析数据进行推理，并将行动回写——在同一个受治理的平台上，中间没有任何管道。
And this is not hypothetical. Today you can already mirror operational data into Snowflake, have Cortex reason over it, and sync the results back to Postgres — analytical and AI output flowing back to the operational system that serves the application.这并非假设。今天你已经可以将操作数据镜像到 Snowflake，让 Cortex 进行推理，并将结果同步回 Postgres——分析和 AI 的输出流回服务于应用的操作系统。
Snowflake has also stated publicly (as of July 2026) that Snowflake-to-Postgres mirroring lands later this year, creating a true bidirectional bridge between the transactional and analytical worlds. That bridge is the architecture the agentic enterprise actually needs: not a one-way export for humans to look at, but a two-way loop a machine can act through.Snowflake 也已公开声明（截至 2026 年 7 月），Snowflake 到 Postgres 的镜像功能将于今年晚些时候推出，从而在事务世界和分析世界之间建立真正的双向桥梁。这座桥梁正是代理式企业真正需要的架构：不是供人类查看的单向导出，而是机器可以借此行动的双向循环。
What good looks like: Design your agentic architecture around the converged plane from the start — map each stage of the loop to a concrete surface:理想形态：从一开始就围绕融合平面设计你的代理架构——将循环的每个阶段映射到一个具体的表面：
Let agents read context from the analytical side, where the joins and the history live; let them act through the operational side, which remains the governed system of record; and treat the write-back path as a first-class, governed surface — because an agent that can act is an agent that can act wrongly, and the controls on what it may write matter as much as the data it may read.让代理从分析端读取上下文（那里有连接和历史记录）；让它们通过操作端采取行动（那里仍是受治理的记录系统）；并将回写路径视为一等公民、受治理的表面——因为能采取行动的代理也可能采取错误的行动，对它能写什么进行控制，与对它能读什么进行控制同样重要。
The anti-pattern to avoid: Building an “agentic strategy” on top of the old one-way pipeline, then wondering why your agents can observe but never act — or act confidently on data that’s six hours old. You’ll have given the agent eyes and no hands, and a memory that’s always slightly out of date. By the time that surfaces — a quarter or two into the rollout — it surfaces as a wrong decision in production, not a warning in a design doc.应避免的反模式：在旧有的单向管道之上构建“代理战略”，然后纳闷为什么你的代理只能观察却无法行动——或者基于六小时前的数据自信地采取行动。你给了代理眼睛却没给它手，还给了它一个总是略微过时的记忆。等到问题浮出水面时（通常在上线一两个季度后），它表现为生产中的错误决策，而不是设计文档中的警告。
Where to start从哪里开始
If you’re an enterprise architect looking at all this and feeling its weight, start here:如果你是一位企业架构师，正面对这一切并感受到其分量，请从这里开始：
- Audit the toll booths. List every CDC job, connector, and batch process whose only purpose is moving first-party operational data into analytics. That list is your retirement backlog.审计过路费。列出每一个唯一用途是将第一方操作数据搬运到分析端的 CDC 作业、连接器和批处理流程。那份清单就是你的退休积压工作。
- Separate first-party from third-party. Native convergence addresses data that originates in (or can move to) your converged platform. External sources still need ingestion. The line tells you what you can actually retire.区分第一方与第三方。原生融合解决了源自（或可以移动到）你融合平台的数据。外部来源仍需摄取。这条线告诉你什么才是你能真正退役的。
- Decide the boundary deliberately. At the entity level, decide what belongs in the operational store, what gets mirrored for analysis, and what an agent will be allowed to write back. Write it down. Give it an owner.明智地决定边界。在实体层面，决定什么属于操作存储，什么被镜像用于分析，以及代理被允许回写什么。写下来，指派所有者。
- Set freshness by workload, not by reflex. Match cadence to business need; resist “as real-time as possible” everywhere.按工作负载设定新鲜度，而非凭惯性。根据业务需求匹配频率；抵制在所有地方追求“尽可能实时”。
- Design the agentic loop now. Don’t bolt agents onto a one-way architecture later. Plan the observe-reason-act loop — including the governed write-back path — while you’re still drawing the diagram.现在就设计代理循环。不要以后再把代理硬塞进单向架构中。在绘制蓝图时，就规划好“观察-推理-行动”循环——包括受治理的回写路径。
The architects who get the most out of this won’t be the ones with the cleverest pipeline. They’ll be the ones who recognised that the pipeline was scaffolding all along — and who took it down to build something their agents can actually reach through.能从中获益最多的架构师，不会是那些拥有最聪明管道的人。而是那些意识到管道始终只是脚手架，并将其拆除以构建代理能够真正触达之物的人。
The rest will spend the next two years giving their AI eyes, and wondering why it never learned to act.其余的人将花费未来两年时间给他们的 AI 装上眼睛，却纳闷它为什么永远学不会行动。
Learn more about how Snowflake Postgres closes the operational-analytical chasm here.点击此处了解更多关于 Snowflake Postgres 如何闭环操作-分析鸿沟的信息。
