Agent Chat UI
为任意 Python 或 TypeScript LangGraph 智能体提供可部署的聊天界面。
工作流仅授予 contents: read，README 也明确区分公开客户端配置与仅应在服务端使用的 LANGSMITH_API_KEY，并说明客户端直连、代理注入和自定义认证的数据路径；因此最小权限、数据流及敏感信息处理有实质依据。依赖覆盖项显示主动缓解传递依赖问题，但材料中没有锁文件、安全扫描或漏洞处置流程，故不满分。用户点击 Continue 后才连接，但聊天会向所选 LangGraph 服务提交运行，未见针对代理工具后续外部副作用的逐项确认机制。未提供撤销、恢复或补偿机制。仓库、包元数据和 MIT 版权归属清楚，但组织发布者身份未经企业注册表验证，且没有更完整的维护者身份链。
README、package.json 和 CI 对 Next.js、pnpm 及主要命令的描述基本一致，Node 22 与固定 pnpm 版本也提高了依赖环境的可获得性。依赖采用大量宽松的脱字符范围，并且所给材料没有锁文件；CI 只检查格式、lint 和拼写，没有展示构建检查。材料也没有错误状态、重试、超时或面向用户的失败消息实现，因此 failure_messages 计零，而不把未执行测试错误地扣到其他标准。
文档覆盖本地开发、已部署站点、生产代理和自定义认证，并同时给出 Python、TypeScript LangGraph 示例，适用场景较清楚。能力边界明确要求 LangGraph server 具有 messages 键，并解释流式隐藏与永久隐藏的不同边界。连接触发主要依赖用户填写 URL、图 ID、认证方案及 Continue 操作，但未展示对无效组合、目标环境或危险代理能力的精细触发校验。环境变量、开发命令和两种生产认证路径处理充分，但定制认证仍要求使用者修改代码。
README 按安装、使用、环境变量、消息隐藏、产物渲染和生产部署组织，安装步骤具体且可直接采用，因此 install_notes 获满分。命名在 README 与 package.json 中大体稳定，并提供多段实用示例；但没有专门 FAQ，部分 API 约定仍依赖外部文档。已明确说明客户端直连不适合生产、API 密钥要求及消息隐藏行为，但没有集中列出浏览器安全、兼容性等限制。MIT 文本完整且与元数据一致。版本仍为 0.0.0，未提供发布策略或变更日志。版权人可识别，但材料没有 CODEOWNERS、支持渠道或明确维护责任，故维护责任仅薄弱成立。
聊天、流式消息控制、Markdown/数学相关依赖以及侧栏 artifact 示例表明输出面向实际交互使用，且通用 LangGraph UI 相比自行搭建界面具有明确增量价值。可本地运行并提供部署路径，降低了启动成本；但材料没有性能、可访问性、运营成本、托管费用或与替代方案的量化比较，所以三项均不足以获得彻底处理的满分。
核心主张可对应到 README 的配置说明、package.json 的依赖和脚本以及 CI 权限与检查项，多个文件对项目形态和工具链形成交叉印证。文档会区分默认开发连接、生产代理和高级自定义认证，也明确指出 nostream 只隐藏实时流而不会阻止最终状态消息，事实与限制分离较好。不过没有架构文档、测试材料、发布记录或安全说明提供更强的独立佐证，因此不评为满分。
- 生产环境不要把 LANGSMITH_API_KEY 放入 NEXT_PUBLIC_ 变量；应使用服务端代理或经过审查的自定义认证。
- 该界面会把聊天内容发送到用户配置的 LangGraph 服务；部署者应独立核实目标服务的数据保留、日志、工具权限和外部副作用。
- 消息隐藏标签和 ID 前缀只是界面呈现控制，不应视为访问控制、数据删除或保密机制。
- 所给材料没有锁文件、安全扫描、构建测试、回滚方案或错误处理证据；上线前需要补充审查。
- 发布者身份未知但并非可疑；在依赖更新、事件响应和支持责任明确前，不应假定企业级维护保障。
这个 Agent 能做什么，适合哪些场景？
Agent Chat UI 是一个 Next.js 应用，用于连接任何状态中含有 `messages` 键的 LangGraph 服务器。用户通过网页配置 Deployment URL、Assistant/Graph ID，并在需要时提供 LangSmith API Key，随后即可提交对话和查看流式回复。界面还能把智能体产生的 artifact 渲染到聊天区右侧的独立面板。应用既可通过 `pnpm dev` 在本地运行，也有现成的托管站点；生产部署则需要 API Passthrough 代理或自定义认证。它不是独立的智能体运行时，也不负责创建图或选择模型，采用前必须已有兼容的 LangGraph 服务。
应用读取 Deployment URL、Assistant/Graph ID、认证方式及可选的 LangSmith API Key，然后通过聊天界面向指定 LangGraph 服务器获取并提交运行。useStream 的扩展 useTypedStream 负责配置 apiUrl、assistantId 和可选的认证请求头；界面通过 on_chat_model_stream 事件显示流式消息，并呈现保存在图状态中的消息。带有 langsmith:nostream 标签的模型不会产生用于实时显示的流事件；若消息 ID 以 do-not-render- 开头并同时使用 langsmith:do-not-render 标签，界面会彻底过滤该消息。组件可从 thread.meta.artifact 获取 artifact 上下文，并使用 Artifact 在聊天右侧面板输出内容。生产环境可以由 langgraph-nextjs-api-passthrough 将请求代理到 LANGGRAPH_API_URL 并在服务端注入 LANGSMITH_API_KEY，也可以修改 useTypedStream，通过 defaultHeaders 传递自定义认证令牌。
- LangGraph 开发者在本机运行 Python 或 TypeScript 图，希望快速获得聊天界面，而不另行开发前端。
- 团队已有部署好的 LangGraph assistant，需要通过 Deployment URL 和 Assistant ID 为内部用户提供交互入口。
- 开发者需要观察智能体的流式消息，同时控制某些模型输出不实时显示或永不出现在界面中。
- 构建写作或内容生成图的团队，希望把生成结果作为 artifact 放在聊天右侧面板中展示。
- 准备上线 LangGraph 应用的工程团队，希望通过 Next.js API 代理隐藏 LangSmith API Key，或接入自己的认证令牌。
这个 Agent 有哪些优点和局限？
- 同一聊天前端可连接 Python 或 TypeScript 实现的 LangGraph 服务，只要求图状态提供
messages键。 - 同时提供交互式配置表单和
NEXT_PUBLIC_API_URL、NEXT_PUBLIC_ASSISTANT_ID等环境变量配置，适合试用和固定部署。 - 明确支持流式消息控制：可阻止实时呈现，也可通过标签与消息 ID 前缀永久隐藏指定消息。
- 内置 artifact 侧栏机制，组件能够通过
thread.meta.artifact展示聊天文本之外的内容。 - 生产路径覆盖现成的 Next.js API Passthrough 和更灵活的自定义认证两种方案。
- 核心操作依赖 LangGraph 服务器及其
messages状态约定，未提供对其他智能体运行时或通用聊天协议的支持证据。 - 默认的客户端直连方式不适合生产环境，因为每位用户都需要自己的 LangSmith API Key 和 LangGraph 配置。
- 生产部署必须额外配置 API 代理或自行实现令牌获取、访问控制和
useTypedStream请求头修改。 - 已部署的 LangGraph 服务通常需要 LangSmith API Key；密钥管理会增加部署和运维成本。
- 安装说明没有给出受支持的 Node.js 与 pnpm 版本，也未提供资源需求或故障恢复说明。
如何安装或部署这个 Agent？
需要可运行 Next.js 项目的环境和 pnpm。可直接创建项目：
npx create-agent-chat-app也可克隆并启动仓库：
git clone https://github.com/langchain-ai/agent-chat-ui.git
cd agent-chat-ui
pnpm install
pnpm dev启动后访问 http://localhost:3000。本地开发还需要一个状态含 messages 键的 LangGraph 服务器。README 未注明具体 Node.js 或 pnpm 版本。
如何使用这个 Agent？
启动应用或访问 https://agentchat.vercel.app，填写 LangGraph Deployment URL 和 Assistant/Graph ID。连接已部署的 LangGraph 服务器时还要填写 LangSmith API Key；Agent Builder 部署需开启 Built with Agent Builder，使认证方案设为 langsmith-api-key。点击 Continue 后即可在聊天界面提交消息。
也可复制 .env.example 为 .env，设置：
NEXT_PUBLIC_API_URL=http://localhost:2024
NEXT_PUBLIC_ASSISTANT_ID=agent
NEXT_PUBLIC_AUTH_SCHEME=修改后重启应用。连接 LangSmith Agent Builder 时设置 NEXT_PUBLIC_AUTH_SCHEME=langsmith-api-key。
生产环境的快速方案是配置：
NEXT_PUBLIC_ASSISTANT_ID="agent"
LANGGRAPH_API_URL="https://my-agent.default.us.langgraph.app"
NEXT_PUBLIC_API_URL="https://my-website.com/api"
LANGSMITH_API_KEY="lsv2_..."其中 LANGSMITH_API_KEY 不得使用 NEXT_PUBLIC_ 前缀；代理会在服务端把它注入发往 LangGraph 的请求。
这个 Agent 与同类方案有什么区别？
与默认的客户端直连相比，API Passthrough 是更快的生产方案：它由服务端代理请求并隐藏 LangSmith API Key，但需要额外的代理配置。自定义认证更灵活，可从客户端访问部署并实施自定义访问控制，但必须在 LangGraph 部署中建立认证流程，并修改 UI 获取令牌和传递请求头。
常见问题
它能直接运行或创建 LangGraph 智能体吗？
messages 键的图或 assistant。什么时候需要 LangSmith API Key？
LANGSMITH_API_KEY 注入密钥；该变量不应带有 NEXT_PUBLIC_ 前缀。可以隐藏模型的内部消息吗？
langsmith:nostream 仅阻止消息实时流式显示，完成后若消息仍被保存到状态中，它还会出现。永久隐藏需要在入状态前给 ID 加 do-not-render- 前缀，并添加 langsmith:do-not-render 标签。是否必须自行托管？
agentchat.vercel.app，也可以通过 npx create-agent-chat-app 创建项目或克隆仓库后自行运行。生产环境可以使用自己的认证系统吗？
useTypedStream，通过 defaultHeaders 传入认证令牌。