Postman 如何用 API 上下文图帮助编码智能体理解微服务

简要描述Brief Description

我们为编码智能体梳理了 115 个微服务——Kamalakannan Nandagopal，PostmanWe Mapped 115 Microservices for Our Coding Agents — Kamalakannan Nandagopal， Postman

目录Table of Contents

• 简介
  Intro
• 115 个微服务
  115 microservices
• 从自动补全到自主智能体
  From autocomplete to autonomous agents
• 现实中的系统是分布式的。
  Real systems are distributed
• 文档会过时
  Docs go stale
• 技能、MCP 和智能体记忆
  Skills, MCPs and agent memory
• 市场推广团队的经验教训
  What the go-to-market team learned
• API 是上下文层
  APIs are the context layer
• 构建 API 上下文图
  Building the API context graph
• 以代码和遥测数据为依据
  Grounded in code and telemetry
• 图表揭示了什么
  What the graph revealed
• 来自真实 PR 的评估񎟃
  Evals from real PRs
• 解读结果
  Reading the results
• 用例：API 发现
  Use case: API discovery
• 用例：API 重新设计
  Use case: API redesign
• 用例：影响评估
  Use case: impact assessment
• 一种失败：数据过时
  A failure: stale data
• 75% 的 PR 涉及 API
  75% of PRs touch APIs
• 一份 21 页的架构评审报告
  A 21-page architecture review
• 接下来是什么？
  What's next
• 要点
  Takeaways

简介Intro

今天我想谈谈，如何让你的编码智能体不止于生成代码，以及 API 上下文或许能成为实现这一目标的答案。我叫卡马尔，是 Postman 的高级工程师。你可能知道，Postman 是一个端到端的 API 平台。不过，除了能让你测试 REST API 和构建 API 的桌面应用之外，嗯……Today I'm going to talk about how you can take your coding agents beyond code generation and how API context might be the answer for that. I'm Kamal. I'm a staff engineer at Postman. And Postman, as you might know, is the end-to-end API platform. But beyond the desktop app that allows you to test your REST APIs and build your APIs, uh

115 个微服务115 microservices

Postman 还有很多云功能。支撑所有这些云功能的是一套庞大的微服务架构。我们有 150 多个微服务和数千个 REST API 端点。嗯，接下来我会结合我们实际的工程用例和工作流，分享我们的编码代理实践，以及我们从中学到的经验，还有我们如何利用 API 上下文图不断提升编码代理的体验和效能。Postman also has uh a lot of cloud features. Empowering all of those cloud features is an extensive microservices architecture. We have more than 150 microservices and thousands of uh REST API endpoints. Uh so, I'm going to be using our real uh engineering use cases and workflows and on top of our coding agent experiences and what we learned from it and how we've been improving the experience and the effectiveness of our coding agents with API context graph.

从自动补全到自主智能体From autocomplete to autonomous agents

所以，我们使用编码智能体的历程，和你们许多人可能经历过的历程相似。最初是行级和函数级自动补全，这就是 Copilot 的时代。接着发展到整个代码库的重构、一次性实现和一次性修复，这就是 Composer 和 Cloud Code 的时代。如今，我们迈向完全自主的编码智能体工作流。智能体可以端到端地启动工作流、进行修改、验证修改、提交拉取请求，甚至还能验证拉取请求。我们发现，编码智能体特别擅长从零开始的项目，以及修复和改进工作。So, our journey with the coding agents started similar to how many of you might have gone through the same journey as well. Starting with line and function level auto completion, this is the Copilot uh days eras. Uh moving on to full code base uh refactors and one-shot implementations and one-shot fixes, uh this is your composer eras and cloud code eras. Now, moving on to fully autonomous coding agent workflows. Uh we have agents that end-to-end start the workflow and then make the changes, verify the changes, send pull requests, and even verify pull requests as well. What we see as the coding agents excelling really well at are greenfield projects or fixes and improvements

真实系统是分布式的。Real systems are distributed

在单个项目的背景下。但生产系统往往要复杂一些。它们通常是由多个微服务组成的分布式系统，往往部署在多个环境中，而且每个环境中还可能有多个不同版本。我们有多个应用，包括前端、CLI 和 API，它们都与后端基础设施通信，而所有这些都分布在数百个代码仓库中，代码也分散在这些仓库里。谈到如何提升编码智能体的性能时，我们首先着手研究的领域是文档。within the context of a single project. But production systems tend to be slightly more complex. They tend to be distributed systems split across multiple microservices. They're often deployed across multiple environments, even multiple different versions in each of these environments. We have several applications, front end, CLI, API, all of them talking to our back end infrastructure, and all of this is spread across hundreds of repos where the code is distributed across all of them. When we think about improving coding agent performance, the first area that we start looking into is documentation.

文档会过时Docs go stale

文档是个很好的起点，呃，但众所周知，开发者都讨厌编写和维护文档。这是额外的负担，会耗费时间，而且随着时间推移，维护起来也会变得棘手。但如果把编写和维护文档的工作完全交给 LLM，研究指出，完全由 LLM 编写和维护的文档往往会随着时间推移呈指数级退化。某种……Documentation is a great place to start, uh but as we all know, developers, we hate writing and maintaining documentation. It's an added overhead. It costs time, and it becomes tricky to go and maintain over time. But if you offload documentation purely to LLMs to author and maintain, research points out that purely LLM maintained and written documentation tends to degrade exponentially over time. Some sort of

技能、MCP 和智能体记忆Skills, MCPs and agent memory

要让它更有效，人工筛选肯定是必要的。Skills 和 MCP 是非常值得考虑的替代方案，但我们都知道，Skills 和 MCP 的效果取决于提供给它们的上下文。对于这种场景，Agent 记忆其实是一个很好的解决方案。嗯，就现实经验而言，这些知识大多可能已经以隐性经验的形式存在于人们脑海中，现在正被转化为编码 Agent 或其运行框架中的 Agent 记忆。我们发现，这方面最大的限制因素是，Agent 记忆仍然非常局限于单个用户，而且目前还没有形成在更广泛的团队或整个工程组织中共享 Agent 记忆的标准模式。在我们尝试为工程团队的编码 Agent 解决这个问题时，我们的市场拓展团队human curation is definitely needed to make it more effective. Skills and MCPs are a really good alternative to look at, but we all know skills and MCPs are only as good as the context that they're provided to. Agent memory is actually a really good solution for uh this scenario. Um in terms of real-world uh experiences, most of this knowledge is probably already tribal knowledge in people's heads, and now it's getting translated into agent memory within the coding agent are the harness. The biggest limitation factor that we see with this is agent memory is still very limited to an individual user, and no standard patterns have now emerged yet in terms of sharing agent memories across your broader teams or across your entire engineering organization. While we were trying to solve this problem for the coding agents on the engineering side, our go-to-market teams

市场推广团队的经验总结What the go-to-market team learned

他们还在为端到端的高管用例构建业务智能体和市场拓展智能体。他们构建了专门定制的智能体，这些智能体基于从多个数据源汇集而来的客户数据打造；此外，他们经过多轮迭代，将来自所有这些数据源的非结构化数据整合为结构化数据，供这些智能体使用。最终，他们搭建出一套高度优化的 RAG 加 GraphRAG 流水线，作为集中式上下文层，让这些独立的业务智能体都能很好地运行，并解决各自的问题。于是，我们开始思考：如何从中汲取经验，又能做些什么来显著提升编码智能体的性能？were also building business agents for go-to-market agents for their end-to-end executive use cases. So, they've been building uh custom agents that are purpose-built with customer data that is brought in from multiple data sources, and they've done several iterations to streamline all of this unstructured data coming in from all of these data sources into a structured data on top of which these agents operate. What they have ended up with is a really optimized like rack plus graph rack pipeline that serves as a centralized context layer that makes all of these individual uh business agents work really well and solve the problem for all of them. So, we started looking at how can we learn from this and what can we do to make the coding agent performance really better?

API 是上下文层。APIs are the context layer

当我们审视这一点时，我们意识到，在分布式系统和微服务架构中，API 就是上下文层。复杂的工程架构通常会拆分为多个域和模型，而每个微服务都负责根据某个模型或域承担一项单一职责；API 则定义了这项职责是什么。系统之间的 API 调用通常是识别跨多个系统的工作流和用户旅程的方式。因此，智能体的能力取决于所获得的上下文。于是，我们踏上了打造最优秀的……之旅。And when we looked at this, what we realized is in a distributed systems and microservices architecture, APIs are the context layer for you. Complex engineering architecture is often broken down into domains and models, and each microservice is responsible for owning one single responsibility as per a model or a domain, and APIs are what defines what that responsibility is. And API calls between systems is usually how you identify workflows and user journeys that span across multiple systems. So, agents are only as good as the context that they're given. So, we set out on a journey to build the best

构建 API 上下文图Building the API context graph

为智能体构建上下文层。因此，我们着手为 Postman 的工程架构构建 API 上下文图谱。整个过程始于识别并编目所有部署在生产环境中的微服务。随后，我们找出了每个 REST API 服务公开的所有端点，并记录了每个端点的具体实现方式，精确到实现它的代码行。我们还梳理了各个服务之间的通信方式，以及每个端点与其他所有端点之间的关联。我们也追踪了数据在整个技术栈中的流向，直至数据库和缓存等底层组件。此外，我们还明确了前端、CLI、API 等应用如何与整个后端架构和后端基础设施交互。context layer for the agents. So, we went out to start building an API context graph for what Postman's engineering architecture looks like. The journey started by identifying and cataloging every single microservice that was on production. And then we identified every endpoint that is exposed by each of these REST API services, and then we captured how each and every one of them is implemented right down to the exact line of code where it was implemented. And we also mapped how each and every service talks to each other, and how each endpoint connects to each each and every other endpoint. We also tracked how the data goes all the way down across the stack, including databases and caches, and all the way down in the entire stack. We also identified how applications like front ends, CLIs, APIs, how they interact with the whole back end architecture and back end infrastructure.

我们会获取所有这些数据，并使用 LLM 对其进行索引，从而构建一个集中且高效的上下文图谱层。但我们始终牢记的一项关键原则是】【。We get give all of this data and we index all of this data using LLM to produce a centralized and effective context graph layer. But one key principle that we had in mind always was

以代码和遥测数据为依据Grounded in code and telemetry

进入上下文图谱的每一个数据点，都必须以确凿事实为依据；这种事实要么是代码库中已实现的一行代码，要么是来自生产环境遥测数据的精确追踪。有了这一基础，我们便踏上了构建上下文图谱的旅程，every single data point that landed on the context graph always had to be grounded down in a hard truth, and that hard truth is either a line of code that is implemented in your code base, or it could be a an exact trace that is coming from a production telemetry. With this in place, we set out on a journey to populate our context graph,

图表揭示了什么What the graph revealed

这就是我们的工程架构大致呈现出来的样子。你会看到一些非常常见、也正如预期般逐渐显现的模式。你会开始看到一个由核心服务组成的中心集群，其中的 API 和服务紧密交织、相互依赖。你还会发现一两个严重臃肿的服务，位于这些系统的外围。位于中心的服务通常会被归类为零级或一级服务。那么，既然我们现在有了上下文图，and this is a snapshot of what our engineering architecture kind of looks like. So, it is some of the very common patterns that you would expect start to emerge. You start to see a central cluster of core services, of very tightly intertwined intertwined APIs and services that are tightly dependent on each other. You find one or two heavily bloated services that are on the outer edges of these systems. The ones at the center is typically what you would classify as tier zero or tier one services. So, now that we have the context graph,

来自真实 PR 的评测Evals from real PRs

当我们开始探讨如何衡量这些工具为编码智能体带来了哪些改进时，我们从组织的 Git 仓库中选取了 Postman Git 上的真实案例。我们选取了提交到 GitHub 仓库的真实 PR，并逐一梳理开发者想要实现什么，以及 PR 最终实际达成了什么。我们还选取了一些重要项目，整理了设计讨论中涉及的关键设计决策和要点。我们将每一项都转化为一项评测，并将事后实际做出的决策作为真实依据，供评测验证。为了运行验证，我们让 Postman 的 AI 智能体连接到 API 上下文图，并使用 Postman AI 智能体对所有这些内容进行了验证。when we start looking at how does how do we measure what does it add in terms of improvements to the coding agents? So, we took real examples from the Postman Git organized from our organization's Git repos. We took real PRs that were raised to the GitHub repos, and for each and every one of them, we identified what the developer was trying to do, and what the actual outcome was at the end of the PR. We also took like important projects, and what were the key design decisions and takeaways that were being discussed in those design discussions. We mapped each and every one of them into an eval, and we mapped what the actual decision that was taken in retrospect as the ground truth that we wanted the evals to confirm into. To to run the validations, we were able to get the Postman's AI agent connects to the API context graph, and we were able to validate all of these against the Postman AI agent as well.

但为了确保比较公平，我们也用一个通用编码代理进行了验证，这里用的是 Claude Code；我们尝试通过类似直接进行 GitHub 代码搜索的方式来验证这些用例。我们还使用了同一个上下文图，并将其作为一项技能提供，然后也将它与通用编码代理进行了比较，这里用的是񎢀But to keep the comparison fair, we also validated this against a generic coding agent, in this case Claude code, and we tried to verify these use cases simply by like a straightforward GitHub code search. We also took the same context graph, and we made it available as a skill, and also compared that against the generic coding agent, in this case

解读结果Reading the results

Claude Code。因此，你会看到结果以这样的图表呈现。我们按照 0 到 5 分的标准为每项评测打分，同时也测量了每次运行所消耗的准确 Token 数量。如果某项结果出现在右上方，就表示智能体表现不错：它在评测中得分很高，但为此消耗了很多 Token。如果出现在左上方，就表示它不仅得分很高，而且完成任务的效率也高得多。如果结果落在虚线之外，就说明它在该项评测中的表现未达到合格标准。接着，我们对日常开发中常见的一些用例和场景进行了归类，看看它们分别落在哪个位置。其中一个我们经常注意到的关键场景是 API。Claude code. So, you're going to see the results of of in a graph plotted like this. So, we scored every eval on zero to five scale and we also measured the exact amount of tokens it took for each of these runs. So, what you will see if something shows up on the top right, it means that the agent did a good job. It was able to score high on the evaluation, but it spent a lot of tokens doing so. If it's on the top left, it did a great job not only scoring high, but it also did it much more efficiently. If something goes beyond the dash line, it just did not meet the bar of what a good score should be on that evaluation. So, then we bucketed like come up some of the common use cases and scenarios that we see in day-to-day development and where do they fall under? One key scenario that we always notice is API

用例：API 发现Use case: API discovery

发现。任何要修改前端或后端、并与其他系统集成的开发者，都需要知道应该调用哪个 API。在实际系统中，你可能会有数百个不同的 API，而且很可能有多个 API 做的是同一件事。所以，在这个例子中，我选了一个简化的场景：要获取特定用户的个人资料名称，应该调用哪个 API？在这项评估中，这是一个纯搜索用例，结果也符合预期。与纯代码搜索相比，使用上下文图的智能体得分相当不错，而纯代码搜索中的智能体表现并不好。Postman 和 Claude 之间略有差异，但差异还没有大到值得我们深入探究的程度。discovery. Any developer who is making a change either to the front end or back end integrating with other systems, what is the right API to call? And in real-world systems, you probably have hundreds of different of the hundreds of different APIs and most likely you have multiple APIs that probably do the same thing. So, in this case, uh a simplified example that I've taken is what is the right API to to call to get the profile name for a particular user. So, in this evaluation, this is a pure search use case and the results are what you would expect. Like with the context graph, the agent scored really well as compared to like pure code search where the agents don't do really well. And there's a slight deviation between like Postman and Claude, but the deviation is not that big enough uh for us to be uh diving deeper into.

第二个，第二个用例才是真正变得……呃】【。The second second use case is where it gets really uh

使用场景：API 重新设计Use case: API redesign

有意思。所以，这就是我们所说的 API 设计和重新设计场景。在这个场景中，假设有一位开发者正在构建一项新功能。为了实现这项功能，他们设计了一个新的 API，也设计了请求输入的 schema。他们定义了它的实现，在自己这边完成了测试，然后将它集成到产品中。他们对产品很满意，也准备好发布了。就在最后一刻，其中一个依赖方找到他们说：“嘿，如果我能多加一个属性传给这个 API 就好了，我想以后某个时候用到它。”于是开发者想：“也许我们没有足够的时间评估所有不同的实现方式。”interesting. So, this is what we call API design and redesign scenarios. So, in this scenario, let's take a developer who's building a new feature and to build that feature out, they've designed a new API and they've designed the schema for the request input. They have defined the uh implementation of it. They have tested it out from their side and then they go integrate it with the product and they're happy with the product and they're ready to ship. At the last minute, one of the dependencies comes to them and then say, "Hey, would it be nice if I just had this one additional property that I would like to pass to to API that I would like to use at a later point in time. So, the developer is like, "Maybe we don't have enough time to evaluate all the different ways in which it can be done.

“要怎么设计合适的 schema？”于是，他们只额外添加了一个上下文，也就是一个自由格式的 JSON 对象，并在代码里添加了一条待办事项：“两周后重新审视这部分，并添加 schema。”这个功能上线了。大家都很满意。 两周后，开发者回来一看，发现那个本该只发送一个属性的特定字段，现在竟然有 15 个属性，而且可能是由一个服务传入的，也可能是五个服务，甚至十个服务。现在，开发者完全不知道请求究竟是以什么样的结构传递到 API 的，也不知道每个消费者各自通过哪些不同方式传递数据。 所以，这就是我所说的：分析每个 API 输入的结构，以及它们为什么会以这种方式被使用。What is the right schema to do this?" So, they just add this one additional context, which is a free-form JSON object, and they add a to-do in the code saying, "Revisit this and add a schema 2 weeks later." The feature ships to production. Everybody's happy. 2 weeks later, the developer comes back and finds out that that one particular property which is supposed to send one attribute now has 15 attributes, and it's being passed by one service or it might be five services. It might be 10 services. Now, the developer has no idea what exactly is the shape in which the request is being passed down uh to the API, and what are all the different ways in which every single consumer has been passing data down to. So, it can be uh So, this is what I call like analysis of a shape of input for each and every API, and why they are used like that.

所以，这件事可能会因为很多原因而变得很困难。首先，在真实场景中，逐一查清所有 API 的使用方可能并不现实。即使你掌握了服务依赖关系和服务地图，要弄清每个使用方所用输入的确切结构，也会非常棘手。工程师通常无法从生产日志中获得足够详细或深入的信息，而且出于隐私原因，这些信息很多时候甚至根本无法获取。即使识别出了这些结构，要准确弄清使用方为什么决定以这种方式传递数据，也会是一个非常非常棘手的问题。 不过，在这个场景中，我们进行了这项评估，然后用 Postman agent 运行它，结果令人惊讶：Postman agent 几乎做得非常出色。这次能取得这样的效果，首先是因为 context graph 能够了解某个 API 的所有使用方；但不止于此，它还能深入查看每个 API 在代码中的具体实现位置，了解相关代码的上下文，从而帮助 agent 理解这项更改为何会做出。So, this can be hard for a bunch of reasons. First, tracking down every single consumer of your API can be impractical in real-world scenarios. Even if you had service dependencies and service maps, finding out the exact shape of input used by each and every consumer can get really tricky. Engineers often lack the detail or depth of information in production logs, and for privacy reasons, it may not even be available at a lot of times. Even if the shapes are identified, finding out exactly why the consumer decided to pass it down like this is a very, very tricky problem. But, in this scenario, when we took this evaluation and then ran it with the Postman agent, what was surprising was the Postman agent almost got it really well. And the thing that helped in this case is, first of all, the context graph having an awareness of every single consumer of an API, but not just that, but having the drill down or the ground truth of where exactly each of these APIs were implemented in code, and the context surrounding that code helped the agent understand why the change was done.

很快，它就能够找出每个调用这个 API 的消费者所对应的确切且独特的形态，因此你可以相当可靠、放心地进行修改。你可以看到，纯代码搜索的效果不太好；但结合 Claude 和这个技能后，效果稍好一些。不过，通常在进行了足够多轮交互后，它就会停下来，等待用户确认下一步该做什么。我们开始看到的另一个非常常见的用例是影响评估。And very quickly, it was able to figure out exact unique shapes for every consumer that was calling this API, and you could be able to make the changes uh quite reliably and confidently. And you can see that the pure code search does not do really well, but with Claude and the skill, it does slightly better, but it tends to give up like after it's done like enough number of turns and waiting for the user to kind of confirm what to do next. So the other very common use cases that we start to see is impact assessment.

用例：影响评估Use case: impact assessment

如何弄清楚某项特定变更会带来什么影响？比如，如果我修改这个 API，可能会有哪些用例？又或者，已经有一个 API，也有一个 V2 API，而我想推出 V3 API。那我该如何先了解 V2 API 是如何使用的，以便设计出更好的 V3 API？这就是我们看到上下文图大显身手的一个场景。你可以看到，Postman Agent 不仅输出质量很高，而且与纯代码搜索相比，所需资源几乎只有一半，甚至三分之一。但这一切并非一帆风顺。How do you figure out what is the impact of one particular change? So if I change this API, what are the potential use cases? Or maybe there's an existing API, there's a V2 API, and I'm interested in introducing a V3 API. How do I understand how the V2 is API V2 API is used first so that I can design a better V3 API. So this is one scenario where we see the context graph really shine well, and you can see that like Postman Agent not only does really well in terms of the quality of the output, but also it's able to do it with almost like half or even 1/3 when compared to pure code search. But this is not smooth sailing all the

一种失败：数据陈旧A failure: stale data

时间。有时我们会看到失败。在这种情况下，我们给它的一个用例是：找出某个特定 PR 中一项变更的影响。该 PR 对一个端点进行了更改，我们要找出所有受该端点影响的下游服务。随后我们开始看到失败，你可以看到图表几乎是反过来的。我们发现 Postman 的评分不但下降了，而且在此过程中还消耗了大量 token。我们对此进行了调查，试图弄清楚失败的原因，结果发现，从编写评估到运行评估这段时间里，出现了新的消费者。因此，填充上下文图很重要，而同样重要的是要让它保持最新。将上下文图与真实情况同步时出现任何延迟，都会导致结果存在偏差。time. Sometimes we see failures, and in this case, one of the use cases that we threw at it was find out the impact of a change in one particular PR where it introduce a change to an endpoint and figure out all the all the downstream services that are affected by that endpoint, and we started seeing a failure, and you can see the graph like almost inverted. We see Postman not only scoring down, but also like consuming a lot of tokens while it did that. And when we investigated in and into it and then tried to understand why it was failing, what we realized was that uh there were new consumers between the time where the eval was written and the time it the evaluation was run. So the context graph is not only important to populate, but it's equally important that you keep it up to date, and any delays in syncing your context graph with the ground truth uh creates gap in the result.

如果结果中存在遗漏，开发者就会立即失去信任，而这会导致他们不再使用。不仅要检测新增的 API 和依赖项，检测 API 和依赖项的移除同样重要，否则也可能造成困惑和问题。所以，你可能会觉得这些用例对你来说不一定常见，但当我们……And if there's a gap in the result, it immediately leads to a loss of trust by the developer, and that translates into lack of usage. Not only detecting new APIs and new dependencies, detecting removals of APIs and removal of dependencies is equally important and that can also lead to confusions and problems. So, you might think that these use cases may or may not be common to you, but when we went

75% 的 PR 会涉及 API75% of PRs touch APIs

回过头来复盘排名前 10 的仓库中提出的所有 PR 后，我们发现，近 75% 的 PR 都会对 API 产生某种影响。这些变更要么会改变 API 的外部接口，要么会接入新的 API，而这两种情况都可能对下游产生很大的连锁影响。因此，我们很清楚这些用例适合用来对比有无上下文图时的前后差异。但一旦掌握了这些信息，我们就能提出以前无法提出的问题。通过这些问题，我们得以使用 Postman 智能体，并对它说：“嘿，请对我们的整个生态系统进行全面的工程分析和端到端架构审查。”这就是我们豁然开朗的时刻。back and retrospected on all the PRs that were raised in the top 10 repos, we noticed that almost 75% of the PRs had some effect on the APIs. So, either these changes are introducing a change to the external surface area of an API or they're introducing an integration of a new API and both of them have can have like really cascading impact downstream. So, these use cases were clear for us to do like a before and after comparison with the context graph and without the context graph, but as soon as we had this information, we were able to ask questions that we were previously not able to ask. And these questions asked allowed us to be able to take the Postman agent and say, "Hey, do a complete engineering analysis and an end-to-end architecture review of our entire ecosystem." So, this is where the light bulb moment happened for us.

当我们让 Postman 代理来做这件事时，When we asked the Postman agent to do this,

一份 21 页的架构评审A 21-page architecture review

它生成了一份长达 21 页的工程报告，逐一梳理了所有弱点和漏洞。报告还为我们找出了不少有意思的洞见，包括依赖循环——这在发生事故时可能会造成严重问题；存在风险的长期迁移——这是技术债的信号；以及单点故障——它们可能引发严重问题，或是迟早会发生的问题。报告还指出了盲点和遥测方面的问题：有些东西虽然已在实现中，却没有反映在遥测数据里。最后，报告给出了明确的行动项，说明 CEO、CTO 和资深工程师各自需要采取哪些措施。it produced a 21-page engineering report going through every single weakness and points of vulnerability. It found out interesting insights for us including cycles of dependencies, which can be really problematic in terms of an incident, risky long-running migrations, which are signals of technical debt, and then single points of failure, which can be really problematic or issues that are waiting to happen, blind spots and telemetry, where stuff that is in the implementation does not reflect in telemetry, and then it came out with clear action items for hey, this is what your CEO, this is what your CTO, and this is what your staff engineers might need to do.

接下来是什么？What's next

除此之外，当我们着眼于还能做哪些进一步改进时，一个突出的领域是引入关于你的业务是做什么的语义层，并将其连接到上下文层，也就是编码代理在工作流中接收的输入。我们正在探索的另一个改进方向是，如何改进并增加对以下问题的推理：为什么会存在某个数据模型？为什么领域会这样映射？为什么会有这个 API，而不是其他 API？为什么应该使用一个 API，而不是另一个 API？所有这些都有助于后续的编码决策，而这一切最终都会转化为真正的On top of all of these things, when we look at what we can do for further improvements, one of the areas that stands out is bringing in the semantic layer of what does your business do and connecting it into the context layer of what your coding agents take as input for their workflows. Another layer of improvement that we're looking into is how can we improve and add additional reasoning of why does a data model exist? Why does the domain map like this? Why does this API exist versus other APIs? Why Why should you use one API over the other API? And all of these helps in subsequent coding decisions and all of that translates into really

要点Takeaways

在日常开发工作流中使用它们时，能够有效地产出成果。下面总结一下我们的收获和经验。我们认识到，API 上下文图可以作为编码代理在真实分布式系统中的上下文层。它能提供高层视图，帮助你回答有关工程架构的问题，而这些问题无法仅在单个代码库或单个微服务的上下文中解答。它缩短了找到解决特定问题的正确方法所需的时间。这一切意味着，我们可以以适当的质量完成工作，或者更高效地完成工作。因此，效率提升既能节省成本，也能让我们更频繁地执行某项任务，从而更频繁地开展相同的评估，包括将评估推进到 PR 级别，甚至直接下沉到工程师使用的开发机器或开发环境中。effective output when you're using them in your day-to-day development workflows. So, takeaways and learnings. We've realized that API context graph serves as the context layer for coding agents in a real-world distributed systems. Gives a high-level view that helps you answer questions about your engineering architecture that you were not able to answer in the context of a single repo or a single microservice. It shortens the time to find the right way to do a particular problem. And all of this means that do the doing this either with the right amount of quality or being much more efficient in being able to do this. So, efficiency translates either into your cost savings, but the way that we see it is if we can do one particular task a lot more efficiently, it means that we can do it more often and this allows us to do the same evaluations at a lot more frequency including bringing it down at the PR level or even bringing it down right down to the development machine or in the development environment where the where the engineer is working on.

因此，我们越早做出决策、越早在生命周期中发现问题，就越能让生成代码的智能体为开发者带来安心感，帮助他们今后更有信心地将变更发布到生产环境。这就是我这边要分享的全部内容。Postman 平台提供了所有这些功能，也都可以通过早期访问使用。演讲结束后，我会在外面等候，有任何问题或想进一步交流，欢迎来找我。我们在大厅对面的 S32 号展位也欢迎大家光临。我这边就分享到这里，非常感谢。So, the sooner we can move the decisions and catch problems earlier in the life cycle, we believe that the agents who are generating code can translate into peace of mind for the developer and help them ship changes to production with a lot more confidence going forward. So, that's everything from my side. All of these capabilities are available within the Postman as a platform. These are also available to use as early access. I will be around outside right after the talk if you have any questions or follow-ups. We also have a booth S32 right across the hall from here. That's everything from my side. Thank you so much.

主持人：哇！Host: Woo!