Model or dataset
baidubce/app-builder avatar
baidubce/app-builder

AppBuilder-SDK: Baidu's Python Client for Qianfan AppBuilder

appbuilder-sdk, 千帆AppBuilder-SDK帮助开发者灵活、快速的搭建AI原生应用

586 stars142 forksPythonApache-2.0

At a glance

What is it?
The AppBuilder-SDK is a Python client that wraps Baidu Qianfan AppBuilder's model calls, 40+ capability components, knowledge base management, and workflow runtime. It is a good fit if you are already inside Baidu Cloud, and a questionable one if you are not.
Who is it for?
Adopt AppBuilder-SDK when your models, knowledge bases, and OCR quota already live in Baidu Cloud and you want one Python client for Playground, the 40+ components, and AgentRuntime. Do not adopt it as a portable LLM abstraction layer, because the component catalog and knowledge base calls are tied to Baidu Cloud endpoints.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 143 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The Problem AppBuilder-SDK Solves: One Client for Baidu's App Platform

Baidu Qianfan AppBuilder is a hosted platform for building AI applications, and the AppBuilder-SDK is its client library. The README describes it as a one-stop development platform client for AI-native application developers. That framing matters, because the SDK is not a framework you run on your own infrastructure. It is a typed Python surface over services that execute on Baidu's side. If you have already published an application in the AppBuilder web console, the SDK's AppBuilderClient is how you reach it from code. If you have models on the Qianfan model platform, Playground is how you call them with your own prompt template. The audience is therefore narrow and specific: Python developers who have chosen Baidu Cloud as their AI backend and want to avoid hand-rolling HTTP calls against each service. The README lists the three functional groups as calling, orchestration, and monitoring, plus deployment. Calling covers models, components, and published applications. Orchestration covers knowledge bases and workflows. Monitoring covers tracing and debug logs. Deployment covers turning an AgentRuntime into an API service or a chat frontend.

Playground, Components, and the Message Object

The core calling primitive is the Message object, which wraps the payload you send to a model or component. The README's first example constructs a Message from a dict with role and question keys, passes a prompt template string to Playground along with a model name, and calls the resulting object. Streaming is a keyword argument: playground(input, stream=True, temperature=1e-10) returns an object whose content can be iterated to print chunks as they arrive. After the stream ends, output.model_dump_json(indent=4) prints the full result including a token_usage block with prompt_tokens, completion_tokens, and total_tokens. Two details stand out. First, the model in the example is DeepSeek-V3.1, not an ERNIE model, which shows Playground is a routing layer over whatever models your Qianfan account can access rather than a single-vendor wrapper. Second, the temperature value of 1e-10 is effectively greedy decoding, a reasonable default for deterministic answers but a strange thing to hardcode in a tutorial. Components follow the same shape. The README shows RagWithBaiduSearchPro being instantiated with a model argument and then invoked via a run method that takes a message and an instruction. The output carries an extra field, search_baidu, containing the retrieved web results with title, url, site_name, and ref_id. That ref_id is presumably what lets you map generated claims back to sources, though the README does not document the mapping.

The RAG Pipeline Is Sold as Atomic Components

The most concrete part of the README is a table mapping the stages of a retrieval-augmented generation pipeline to individual components. Document parsing has five entries: DocCropEnhance for correction and enhancement, DocFormatConverter, DocParser, ExtractTableFromDoc, and GeneralOCR for high-precision text recognition. Chunking is DocSplitter. Vectorization is Embedding. Index construction and retrieval are covered by two retrievers, BaiduVectorDBRetriever and BaiduElasticSearchRetriever, which means you pick your store rather than getting one by default. Answer generation is where the catalog gets interesting: QAPairMining, SimilarQuestion, TagExtraction, IsComplexQuery, QueryDecomposition, QueryRewrite, MRC, and HallucinationDetection. These are LLM-backed components rather than deterministic utilities, and the README labels them as advanced capability components as opposed to the basic ones used earlier in the pipeline. The design intent is composability. The README points to a RagWithBaiduSearchPro cookbook notebook for an end-to-end example. What the table does not tell you is how these components are priced or rate-limited individually, and that gap is the main practical risk in building on them.

Installing and Authenticating

Installation is a single pip command, and Python 3.9 or later is required. The README gives the exact invocation: python3 -m pip install --upgrade appbuilder-sdk. Java and Go versions exist, along with a Docker image, but those are documented in a separate install page rather than in the README body. Authentication is environment-based. Every example sets os.environ["APPBUILDER_TOKEN"] to a personal token before constructing any client object, and the README repeats the instruction to replace the placeholder with your own token. There is no mention of a config file, a credentials chain, or per-call token override in the material provided, so the environment variable appears to be the only documented path. The README also states that calling components requires claiming a free trial quota, with a link to Baidu's resource list console. That is an important operational detail: a valid token alone does not guarantee a component call will succeed. The README's release notes point to a changelog file for version history, and the most recent release listed is v1.1.1 from September 2025.

AgentRuntime Deployment and What It Actually Gives You

The orchestration layer exposes three abstractions named in the README: Message, Component, and AgentRuntime. Message is the payload wrapper seen in the calling examples. Component is the unit of capability. AgentRuntime is the composition layer, and it is the one with deployment options attached. According to the README, AgentRuntime can be deployed as an API service built on Flask and gunicorn, or as a conversational frontend built on Chainlit. There is also a separate tool, appbuilder_bce_deploy, described as deploying a program to Baidu Cloud to expose a public API and connect with AppBuilder workflows. The README also claims the orchestration layer can interoperate with LangChain and OpenAI ecosystem capabilities. That claim is stated but not demonstrated in the material provided, so treat it as a direction rather than a verified integration path. The practical consequence of the deployment story is that AgentRuntime is where the SDK stops being a thin client and starts being a small application server. If you only need model calls, you will never touch it.

The Baidu Cloud Coupling Is the Real Constraint

The SDK's components are described as originating from Baidu's ecosystem, and the retriever options are Baidu VectorDB and Baidu ElasticSearch. The knowledge base management interface, KnowledgeBase, operates on knowledge bases in the AppBuilder web console. The deployment tool targets Baidu Cloud specifically. Taken together, this means the SDK is not a neutral layer you can point at arbitrary backends. Swapping the vector store means moving to a component the SDK does not appear to provide, and swapping the model provider means leaving the Qianfan model platform. The second limitation is documentation depth outside the README. The README links to per-component README files under python/core/components, and to a changelog, which suggests the detail exists, but the top-level document does not describe error handling, retry semantics, rate limits, or the shape of failures when a component quota is exhausted. The third is the interop claim with LangChain and OpenAI, which is asserted without an example in the supplied material. For a team evaluating this SDK, the honest position is that the calling surface is well illustrated and the operational surface is not.

How It Compares to LangChain and LlamaIndex

The closest alternatives for the same job are LangChain and LlamaIndex, and the difference is architectural rather than feature-level. LangChain and LlamaIndex are libraries that run entirely in your process: you supply the model client, the vector store client, and the embedding function, and the framework wires them together. AppBuilder-SDK inverts that. The components execute as hosted services behind a Baidu endpoint, so what you get from the SDK is a typed request and response, not an implementation. That inversion has real consequences. You get less code to maintain and no infrastructure to run for parsing, OCR, or the LLM-backed components. You also get no ability to inspect, modify, or self-host those components, and your pipeline's behavior is tied to a service you do not control. The retriever choice makes the split concrete: with LangChain you would write an adapter for whichever vector database you already run, while AppBuilder-SDK hands you two Baidu options and expects you to pick one. If your data cannot leave Baidu Cloud, that is a feature. If it can, you are paying a portability cost for convenience.

Licence, Maintenance, and Upgrade Cost

The repository is licensed under Apache-2.0, which permits commercial use, modification, and redistribution provided you retain the licence and notices. That is a permissive licence with no copyleft obligation on your own code, and it is the same licence used by LangChain. It says nothing about the terms of the Baidu Cloud services the SDK calls, which are governed separately and are not described in the README. On maintenance, the release cadence visible in the supplied material is roughly quarterly: 1.0.6 in May 2025, 1.1.0 in June 2025, and v1.1.1 in September 2025. The repository is not archived and the last push date is April 2026. The README's own version banner still reads 1.1.0 even though v1.1.1 is the latest release, which is a small but telling inconsistency in how the documentation is maintained. Upgrade cost is mostly a function of how much of the component surface you use, since each component has its own README and its own service contract. Pinning appbuilder-sdk to a specific version is the safe default until you have read the changelog for the versions you are skipping.

Editorial conclusion

Adopt AppBuilder-SDK when your models, knowledge bases, and OCR quota already live in Baidu Cloud and you want one Python client for Playground, the 40+ components, and AgentRuntime. Do not adopt it as a portable LLM abstraction layer, because the component catalog and knowledge base calls are tied to Baidu Cloud endpoints. Before committing, verify that your APPBUILDER_TOKEN works against the specific component you need, since the README states components require a separately claimed free trial quota.

Official sources

  1. baidubce/app-builder on GitHub
  2. License: Apache-2.0
  3. Project website
  4. README
  5. Releases
Community notes

Community notes