Skip to main content

Search: #可追溯性

无原创,纯转发
  1. Agent Trace:为 AI 写的代码建立“可追溯”标准

    Agent Trace 是一个开放规范,用来记录代码中哪些部分来自 AI、哪些来自人类,并把相关的模型信息、对话链接等“出处”一并纳入版本控制工作流中。它强调厂商中立,让不同工具都能读写同一套归因数据。

    核心想解决什么

    • 随着 Agent/代码助手产出越来越多代码,团队需要更清楚地知道:哪些改动是 AI 生成、用的是什么模型、对应哪次对话/会话。
    • 这不是法律意义的“所有权”或“版权”判定,而是工程层面的来源记录可审计性

    主要目标

    互操作性:任何兼容工具都能写入/读取归因记录
    细粒度:支持到**文件级、行号范围(line range)**的归因
    可扩展:允许各家在不破坏兼容的情况下增加自定义元数据
    人和 Agent 都能读懂:尽量不依赖特定 UI 才能理解

    不做什么(边界很明确)

    • 不处理代码法律归属、版权问题
    • 不追踪训练数据来源
    • 不做质量评估(不判断 AI 代码“好或坏”)
    • 不绑定任何界面或产品形态

    规范长什么样(概念速览)

    Agent Trace 的基本单位是 Trace Record(JSON 记录),典型字段包括:

    version / id / timestamp:规范版本、记录 ID、时间戳
    vcs:版本控制信息(如 git commit SHA;也支持 jj/hg/svn)
    tool:生成该记录的工具及版本
    files:文件列表;每个文件下按 conversation 分组
    conversations.url:指向产生这段代码的对话链接
    ranges:该对话贡献的行号范围(可选 content_hash 用于跨移动追踪)
    metadata:自定义扩展字段(建议用反向域名避免冲突,如 dev.cursor

    实现与落地

    • 规范本身不规定 traces 存哪:可以是本地文件、git notes、数据库等。
    • 提供了一个参考实现(含存储层、hook 集成),示范如何在文件变更时自动捕获归因信息。

    链接:https://agent-trace.dev/
    #AI编程 #代码归因 #工程规范 #可追溯性 #开发工具 Agent Trace
  2. 用 Payload CMS + Vercel AI SDK 搭建“可运营”的 AI 应用

    把 AI 做到生产可用,更多是架构问题:提示词不该写死在代码里,长任务要能可靠重试,Embedding 要能查询,输出要结构化可校验,更关键的是——要能看见系统到底“说了什么、做了什么”。

    这篇文章分享了 InnoPeak 在 FinSureTech 场景下的一套实践组合:用 Payload CMS 做“可视化、可配置的 AI 后端”,用 Vercel AI SDK 做“结构化生成与工具调用的运行层”,形成一条从配置、执行到观测的闭环。

    1) 用 Payload 管理 Prompt 与模型选择(不发版也能调)

    • 把系统/用户提示词做成模板(如 Handlebars),集中放在 Payload 的 globals
    • 模型 ID 用受控下拉选项管理,避免随意输入造成线上不可控
    • 非开发同事也能在后台安全修改提示词与模型策略,应用逻辑保持稳定

    2) 在后台“可视化”JSON Schema,提升结构化输出可靠性

    做结构化输出(JSON schema)时,最大的成本在测试与迭代。作者的做法是:

    • 在 Payload Admin 里直接渲染/展示 schema
    • 让开发者一键复制到测试对话或本地 LLM 环境验证

    这样能更快发现:字段缺失、类型不匹配、约束不被遵守等问题。

    3) 用 Payload Jobs Queue 跑长任务:重试、编排、定时都省了

    AI 工作流常有“慢”和“不稳定”:Embedding 生成、文档扫描、分段处理、失败重试……在 serverless 环境尤其麻烦。Payload 的 Jobs Queue 提供:

    • 任务与工作流编排
    • 重试与调度
    • 可用 Vercel CRON 或其他调度器触发

    把“队列基础设施”从应用里剥离出来,专注业务流程。

    4) Embedding 直接存进 Payload 的 Postgres(pgvector),再用 Drizzle 查

    Payload 本身不内建向量字段与索引,但可以用 schema hooks 扩展:

    beforeSchemaInit 增加 vector 列,让生成的 Drizzle schema 也包含它(全类型化)
    afterSchemaInit 创建 HNSW 向量索引、以及 GIN 文本索引(便于混合检索)

    随后即可在 API route / server action / task 里做相似度检索与排序,实现 RAG 的“数据库内闭环”。

    5) 记录 Token 与完整消息:成本可控、行为可追溯

    为了线上可观测性,作者在 Payload 里建了 TokenUsage 集合,保存:

    • 输入/输出/总 token(含缓存、推理 token 等)
    • 与模型交互的完整 messages(包含 tool calls)

    并通过 Vercel AI SDK 的 onFinish 钩子自动落库。好处是:复盘提示词与输出、定位异常、优化成本都有依据。

    结论很明确:AI 应用要“能跑、能改、能查、能追踪”,需要的不只是模型能力,更是把配置、数据与运行时纳入同一套可运营系统。

    原文链接:https://finly.ch/engineering-blog/916926-building-ai-native-applications-with-payload-cms-and-the-vercel-ai-sdk

    #PayloadCMS #VercelAISDK #AInative #RAG #可观测性 Finly - Building AI-Native Applications with Payload CMS and the Vercel AI SDK
1px