盐田做网站的公司北京的网络公司有哪些

盐田做网站的公司,北京的网络公司有哪些,wordpress简约商城,一个网站需要多长时间2025 年是 Agentic AI 爆发的一年。从 OpenAI 的 Agents SDK 到 Anthropic 的 MCP (Model Context Protocol)#xff0c;从 LangGraph 到 CrewAI#xff0c;构建 AI Agent 的工具链正在快速成熟。更重磅的是 Linux 基金会专门成立了 Agentic AI 子基金来推动 Agent 相关开放标…2025 年是 Agentic AI 爆发的一年。从 OpenAI 的 Agents SDK 到 Anthropic 的 MCP (Model Context Protocol)从 LangGraph 到 CrewAI构建 AI Agent 的工具链正在快速成熟。更重磅的是 Linux 基金会专门成立了 Agentic AI 子基金来推动 Agent 相关开放标准和工具的发展。但随之而来的问题是当 Agent 出了问题我们怎么排查当 Agent 表现不佳我们怎么优化这就是 Agent 可观测性Agent Observability要解决的问题。过去一年这个领域热度飙升。Datadog 在 2025 年 6 月的 DASH 大会上发布了 AI Agent Monitoring[^1]OpenTelemetry 正在制定 GenAI Semantic Conventions[^2]LangSmith、Langfuse 等专用平台快速崛起。一个核心问题浮出水面传统的可观测性技术栈——Metrics、Logs、Traces 这三大支柱——还能用吗还是我们需要一套全新的方案本文的答案是旧瓶还能用但确实需要装新酒。而且当你认真审视这些新酒的特征会发现它们指向一个更深层的变化——Observability 2.0。一、旧瓶传统可观测性的基础仍然有效先说好消息我们不需要推翻现有的可观测性体系。三大支柱依然成立。Agent 应用同样需要Metricstoken 用量、调用延迟、成本统计Logsprompts、responses、tool 输出Tracesagent 执行流程、多步推理路径OpenTelemetry 正在成为 GenAI 的事实标准。OTel 的 GenAI Semantic Conventions 已进入正式规范v1.37定义了gen_ai.request.model、gen_ai.usage.input_tokens、gen_ai.provider.name等标准属性[^3]。Datadog、Langfuse 等平台已原生支持这套规范。❝Traces 本质上是结构化 logging 的特殊形式。—— 引用 [^4]Agent 可观测性不是要推翻旧体系而是要扩展它。但问题在于扩展到什么程度需要哪些新能力这正是 Agent 场景带来的挑战。本文将尝试分析和解答。二、新酒上数据形态与观测目标的本质变化2.1 半结构化数据的爆炸传统可观测性处理的数据类型相对清晰结构化 Metrics数值型时序数据schema 固定非结构化 Logs文本流自由格式结构化 Tracesspan 树层级明确但 Agent 带来了大量半结构化数据数据类型特征Prompts文本 模板变量 系统指令 上下文注入Tool Calls函数名 动态参数可能嵌套 返回值结构各异Memory Statekey-value 复杂嵌套 随对话演进Multi-turn Context对话历史 角色标识 元数据一个典型的 Agent 执行事件可能包含几十甚至上百个字段而且每次 tool call 的返回结构都可能不同。这不是简单的数据量变大而是数据形态的根本变化。传统方案怎么处理要么把这些数据塞进 Logs丢失结构难以查询要么塞进 Tracesschema 过于僵化无法表达动态结构。两种方式都不理想。Datadog 在其 Agent 监控方案中强调了这一点[^5]❝Agents often maintain internal memory—such as CrewAI’s short-term and long-term memory or LangGraph’s state—which influences their decisions but may not be exposed in standard logs or spans.Agent 通常维护内部记忆——如 CrewAI 的短期和长期记忆或 LangGraph 的状态——这些影响决策但可能不会暴露在标准的 logs 或 spans 中。2.2 数据规模一个典型 Agent 应用会产生多少可观测数据让我们用数字说话。假设一个中型 Agent 应用场景设定日活用户DAU10 万每用户每天平均交互5 次每次交互平均 LLM 调用3 次包括 planning、tool calling、response generation数据量估算指标计算数值日 LLM 调用数100K × 5 × 3150 万次/天每次调用 token 数输入 2K 输出 1K典型 RAG 场景~3K tokens日 token 总量150万 × 3K45 亿 tokens/天单个 Wide Event 大小50-200 字段含 prompt/response2-8 KB日可观测数据量150万 × 5KB取中位数~7.5 GB/天月可观测数据量7.5GB × 30~225 GB/月如果是大型应用百万 DAU数据量会达到2 TB/天。业界真实案例LangfuseLLM 可观测平台生产环境处理每分钟数万事件后端存储达到数十亿行级别[^17]。小规模部署定义为每月 100 万 traces。LaminarBrowser Agent 可观测平台每天处理数十万 browser session events曾因 SDK bug 在单日产生超过 10 亿次写入[^15]。ClickHouse LogHouse内部可观测平台存储100 PB 未压缩数据近 500 万亿行[^18]。关键洞察Agent 可观测数据的特点不仅是量大更是维度高。Honeycomb 的经验表明成熟的可观测数据集通常有200-500 个维度[^19]。这意味着传统的 metrics 聚合方式预定义维度根本无法覆盖 Agent 场景的分析需求。2.3 从系统行为到语义质量第三个不同是观测的目标也在发生变化。传统监控回答的问题服务是否可用✅ / ❌延迟是多少P50 120ms, P99 450ms错误率是多少0.3%这些是系统行为层面的指标。但 Agent 监控需要回答一些完全不同的问题回答是否准确Factual Correctness回答是否相关Topic Relevancy推理是否合理Reasoning QualityTool 选择是否正确Decision Quality是否存在幻觉Hallucination DetectionDatadog 的 LLM Observability 产品内置了一系列质量检查[^6]Failure to Answer是否未能回答、Topic Relevancy主题相关性、Toxicity毒性、Negative Sentiment负面情绪。这些都不是传统 APM 会关心的指标。我们正在从观测系统行为转向观测语义质量。这意味着我们不能只记录调用了什么还要理解为什么这样调用以及结果质量如何。这需要深入到调用内部保留完整的上下文。2.4 反馈闭环可观测性驱动 Agent 演进传统可观测性是被动的——系统出了问题告警响了工程师开始排查。Agent 可观测性需要主动的反馈闭环Prompt 设计 → 部署 → 观测效果 → 分析模式 → 优化 Prompt → 再部署 → ...这个闭环的周期决定了 Agent 演进的速度。正如 Honeycomb CEO Charity Majors 所说[^7]❝Observability 2.0 is very much about how you develop your code… when you have an observability 2.0 mindset and toolkit, you can see where that time is going.Observability 2.0 关乎你如何开发代码……当你拥有 2.0 的思维和工具时你能看到时间花在哪里。对 Agent 开发来说这一点尤为关键。Agent 的行为是非确定性的——相同的输入可能产生不同的输出。反馈周期从天缩短到分钟迭代速度将大幅提升。可观测性不再只是运维工具而是 Agent 智能化演进的核心基础设施。三、新酒下Multi-Agent 时代的可观测性挑战单个 Agent 的可观测性已经够复杂了。当多个 Agent 协作时问题会指数级放大。3.1 Observability TrilemmaGalileo 在其博客中提出了可观测性三难困境Observability Trilemma[^8]Completeness完整性 /\ / \ / \ / \ /________\ Timeliness Low Overhead 实时性 低开销Completeness捕获所有 agent 的所有行为Timeliness数据实时可见支持快速反馈Low Overhead不显著影响 agent 性能❝This presents what we call the “observability trilemma” – you can have completeness (capturing all data), timeliness (seeing it when needed), or low overhead (not disrupting your system) – but rarely all three simultaneously.这就是我们所说的可观测性三难困境——你可以有完整性、实时性或低开销但很难同时拥有三者。这个三难困境并非绝对但它准确描述了团队在实践中面临的权衡。在单 Agent 场景下可以通过取舍来应对。但在 Multi-Agent 协同场景下每个 Agent 都有自己的 memory state 需要追踪Agent 之间的通信、handoff、任务委托需要关联涌现行为Emergent Behaviors难以用预定义指标检测问题呈指数级放大。3.2 状态的黑洞Agent 的决策依赖于内部状态Short-term Memory当前对话的上下文Long-term Memory持久化的知识和偏好Framework StateLangGraph 的 state、CrewAI 的 memory问题是这些状态往往不透明。传统的 Trace 视图是这样的呈黑盒状Input → [Black Box] → Output但理解 Agent 行为我们需要看到Input → Planning推理过程 → State Query查询记忆 → Tool Selection为什么选这个工具 → Tool Execution执行结果 → State Update状态变更 → Response Generation → Output我们需要深入到每一步每一步的状态都应该可观测因为都会影响到最终 Agent 的效果。Datadog 在他们的产品介绍中强调了这一点[^5]❝This includes visibility into agent memory states such as CrewAI’s short-term and long-term memory or LangGraph’s state, which can be crucial for understanding decision-making processes.这包括对 agent 记忆状态的可见性如 CrewAI 的短期和长期记忆或 LangGraph 的状态这对理解决策过程至关重要。Agent 的记忆和状态必须成为一等公民。不观测状态就无法理解决策不理解决策就无法优化 Agent。这是跟传统 APM 一个非常显著的不同。3.3 分布式追踪的断裂以 MCPModel Context Protocol为例一个典型的调用链路User → Agent (Client) → LLM Provider → MCP Server → External Tool | | Trace A Trace B (断裂!)Glama 的技术博客详细讨论了这个问题[^9]❝主要的架构挑战在于将这两条路径统一到单个分布式追踪中……要实现真正的端到端追踪客户端必须将 Trace ID 传播到发送给 MCP Server 的请求中。当前的挑战Client 端 trace 和 Server 端 trace 如何关联需要 W3C Trace Context 标准在所有组件间传播缺乏社区共识的 semantic conventions如mcp.tool_name、agent.session_idOpenTelemetry 正在制定 Agent Framework Semantic Conventions[^10]定义了 Tasks、Actions、Agents、Teams、Artifacts、Memory 等概念。但距离成熟和广泛采用还有距离。Multi-Agent 可观测性的核心难题是跨边界的 context 传播。这不仅是技术问题更是标准化问题。当然这个问题在微服务架构时代也没有解决的很好。四、进一步洞察这本质上就是 Wide Events让我们回顾前面发现的挑战半结构化、高维度、上下文丰富的数据需要事后分析语义质量不能只靠预聚合 metrics需要保留原始数据支撑快速反馈闭环需要统一存储消除 data silo关联 metrics/logs/traces这些特征是不是很眼熟这正是 Charity Majors 提出的 Observability 2.0 / Wide Events 要解决的问题4.1 什么是 Wide EventsWide Events 是 Honeycomb 提出的数据模型核心思想是用单一、宽格式的结构化事件取代分散的 metrics/logs/traces作为可观测性的单一事实来源。Charity Majors 在 2024 年底正式提出了 Observability 2.0 的概念[^11]❝我们把 metrics、logs、traces 这些三大支柱的工具叫做 Observability 1.0。像 Honeycomb 这样基于任意宽度的结构化日志事件、单一事实来源构建的工具这是 Observability 2.0。Wide Events 的核心特征高基数High Cardinality可以包含user_id、trace_id这样的唯一标识高维度High Dimensional单个事件可能有几十上百个字段上下文丰富Context-rich保留完整的请求上下文单一事实来源Single Source of Truth从原始事件派生 metrics/logs/traces而不是分开存储如果你没有了解过可以来阅读这篇文章《Wide Events 101何为宽事件为何需要以及如何落地》。4.2 Agent 数据天然就是 Wide Events看一个典型的 Agent 执行事件{ timestamp: 2025-01-15T10:30:45.123Z,trace_id: abc123,session_id: user-session-456,agent_name: research-assistant,model: claude-sonnet-4-20250514,input_tokens: 1523,output_tokens: 892,latency_ms: 2340,prompt: Based on the users question about...,response: Here are my findings...,tool_calls: [ {name: web_search, params: {query: ...}, duration_ms: 450} ],reasoning: User asked about X, decided to search because...,memory_state: {short_term: [...], long_term_refs: [...]},quality_score: 0.85,topic_relevancy: 0.92}这就是一个典型的 Wide Event高基数trace_id、session_id、高维度几十个字段、上下文丰富保留了 prompt、response、reasoning。4.3 为什么 O11y 1.0 方式处理 Agent 数据会很痛苦如果用传统三大支柱的方式做法问题把 prompt/response 塞进 Logs丢失结构难以分析把 tool calls 塞进 TracesSchema 僵化无法表达动态结构预聚合 token usage 成 Metrics丢失上下文无法回溯分析哪个 prompt 导致了高延迟分开存储再关联Data silo跨系统查询困难我们见过团队用传统方案排查一个幻觉问题需要跨 3 个系统拉数据、手工关联 trace_id耗时数小时才能定位到问题 prompt。如果用 Wide Events同样的分析只需要一条查询。Charity Majors 一针见血地指出[^12]❝The cost of the time engineers spend laboring below the value line—trying to understand their code, their telemetry, their user behaviors—is astronomical. Poor observability is the dark matter of engineering teams.工程师在价值线以下挣扎的时间成本——试图理解代码、遥测数据、用户行为——是天文数字。糟糕的可观测性是工程团队的暗物质。4.4 Agent 场景让 Wide Events 从更好变成必须Agent 可观测性需求Wide Events 如何满足半结构化数据存储原生支持高维度、动态 schema语义质量分析事后从原始数据派生任意指标快速反馈闭环不修改 instrumentation 即可定义新分析维度状态追踪单一事实来源保留完整上下文统一关联三大支柱成为同一数据的视图在传统应用中Wide Events 是更好的选择在 Agent 场景中它几乎是必须。Agent 可观测性不是一个全新的领域而是Observability 2.0 的最佳实践场景。五、技术选型Wide Events 需要什么样的数据库理解了 Wide Events 的理念下一个问题是怎么落地5.1 核心能力需求统一存储— 一个系统处理 metrics、logs、traces 和半结构化数据消除 data silo数据孤岛云原生架构— 对象存储 计算存储分离成本可控且弹性扩展实时处理— 低延迟摄入和查询支持 dashboard 和 alerting派生能力— 从原始事件实时派生 metrics 和聚合不需要预处理灵活查询— 支持 routine queriesdashboard和 exploratory queriesad-hoc 分析开放标准— 兼容 OTel 协议避免供应商锁定关键是把复杂度从 Agent 端转移到存储层——Agent 只负责发送原始事件存储层负责处理、聚合、索引。5.2 应对 Observability Trilemma挑战解决思路Completeness统一存储消除 data silo原生支持半结构化数据Timeliness流式处理引擎实时派生指标计算存储分离支持弹性查询Low Overhead原始数据写入开销低聚合在存储层异步完成5.3 行业趋势数据库厂商的布局Wide Events 和 Agent Observability 的交叉点正在成为数据库厂商的新战场。ClickHouse在 2025 年推出了 ClickStack[^13]明确采用 Wide Events 作为核心数据模型并收购 HyperDX 补全 UI 层。其 LLM Observability 方案[^14]支持 OpenAI Agents、LangChain 等框架的追踪Laminar 等公司已在用它构建 AI Browser Agent 可观测性平台[^15]。GreptimeDB作为统一可观测性数据库提出三大支柱成为视图的理念[^16]——Metrics、Logs、Traces 不是独立的存储系统而是对同一底层数据的不同查询视图。其内置的 Pipeline预处理引擎支持在数据写入时进行结构化解析和字段提取Flow Engine流计算引擎支持从原始事件实时派生聚合指标无需预处理管道。这种架构天然适合 Agent 场景写入高维度原始事件按需派生 metrics 和 traces。这种趋势说明什么Wide Events 不再只是理论概念而是正在成为下一代可观测性存储的实际架构选择。无论是 OLAP 数据库如 ClickHouse还是统一可观测性数据库如 GreptimeDB都在向统一存储、原始数据优先的方向演进。对于 Agent 可观测性来说这是好消息——底层基础设施正在成熟。六、总结旧瓶依然有用。Metrics、Logs、Traces 的框架OpenTelemetry 的标准这些可观测性的基础设施仍然适用于 Agent 场景。但确实需要新酒。Agent 带来了数据形态的根本变化半结构化、高维度、观测目标的转变从系统行为到语义质量、以及新的使用模式快速反馈闭环驱动演进。更深层的洞察是这些新酒本质上就是 Wide Events。Agent 可观测性不是一个全新的领域而是让 Observability 2.0 的价值更加凸显的场景。在传统应用中Wide Events 是更好的选择在 Agent 场景中它几乎是必须。甚至我们可以下个结论❝Agent Observability 是 Observability 2.0 的第一个杀手级应用场景。技术选型的关键统一存储、原始数据优先、弹性扩展、实时处理。想持续关注 Agent 可观测性建议如下行动关注 OpenTelemetry GenAI SIG 的进展尝试 Langfuse、ClickStack 或 GreptimeDB 的 Agent 追踪能力参与 Agent Framework Semantic Conventions 的讨论关注我们公众号我们将陆续推出一系列文章解析 Agent 可观测性标准化正在进行中现在是参与和塑造这个领域的好时机。如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】